Tracking offers across multiple channels

ABSTRACT

Provided is a process, including: obtaining a coupon issued by a merchant, the coupon being redeemable both on-line, at the merchant&#39;s website, and in-store, at a physical location of the merchant; sending the coupon to publishers for presentation to consumers by the publishers on user devices of the consumers; and receiving indications from the user devices of the consumers that the consumers interacted with the coupon, the indications indicating a consumer selection of an in-store redemption option or an on-line redemption option.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is continuation of U.S. patent application Ser.No. 15/956,910 filed Apr. 19, 2018, which is a continuation of U.S.patent application Ser. No. 14/489,875 filed on 18 Sep. 2014, whichclaims the benefit of U.S. Provisional Patent Application 61/882,130filed 25 Sep. 2013, which are hereby incorporated by reference in itsentirety for all purposes.

BACKGROUND OF THE INVENTION 1. Field

The present invention relates generally to offers and, morespecifically, to systems for electronically tracking offers acrossmultiple channels.

2. Description of the Related Art

Often merchants enlist third parties to promote offers, such as coupons,sales, rebates, favorable shipping terms, or other changes in termsfavorable to consumers. This practice in recent years has expandedgreatly in the context of the Internet. In some cases, a given offer maybe distributed by thousands of publishers on the World Wide Web (orother content-publishing platforms, such as those having nativeapplications on mobile devices) to millions of consumers. Each publishermay draw an audience based on content gathered, curated, or created bythat publisher, and merchants may compensate a publisher for presentingthe merchant's offers to that publisher's audience. Consequently,consumers become aware of potentially valuable offers; merchants benefitfrom wide distribution of their offers; and publishers are compensatedfor providing content valued by their audience.

Generally, merchants seek wide distribution of their offers to largenumbers of publishers and consumers, in some cases according togeographic or publisher-type constraints consistent with a merchant'sbrand and geographic reach. But managing a large network of publishersis difficult and expensive. For instance, simply determiningcompensation can be challenging at large scales. Often, publishers arecompensated based on revenue that is received by the merchant fromvisitors to the publishers website or other application, and keepingtrack of which publishers should be credited for which transactions canbe very expensive, particularly when a merchant wishes to work withthousands of publishers potentially leading to millions of transactions.Further, selecting, communicating with, and establishing contractualrelationships with thousands of publishers can be expensive, complex,and labor intensive.

Similarly, many publishers wish to work with a relatively large numberof merchants in order to receive a relatively large number of offers topresent to the publishers' audiences. Yet many publishers lack theresources to track, across hundreds of merchants, which offers led tocompensable consumer actions or establish contractual relationships withhundreds of merchants, let alone accommodate a potentially diverse setof merchant-specific protocols and business processes for communicatinginformation about offers.

To shield both merchants and publishers from this complexity, manyon-line offers are distributed through affiliate-network systems. Thesecomputer systems act as an intermediary between publishers andmerchants, distributing offers to publishers, allocating credit topublishers for revenue they generate for merchants, simplifying theprocess of establishing contractual relationships, and standardizingcommunication protocols and business processes. (Though not allaffiliate-network systems necessarily fill all of these roles.) Oftenmerchants and publishers access these computer systems throughrole-specific interfaces presented over the Internet, or access may beprovided via a human representative of the entity operating theaffiliate-network system who updates the system on behalf of merchantsor publishers.

Many affiliate-network systems are ill-suited to address future trendsin the distribution of offers expected by applicants. As smart phonesand other mobile user devices proliferate, it is becoming increasinglyviable and desirable to present and redeem offers both on-line, when theconsumer is away from (or not necessarily at) the geographic location ofa merchant's brick-and-mortar store, and in-store, when the consumer isphysically present at a merchant's location. Further, as consumersintegrate more networked devices and network-accessible accounts intotheir lives, many consumers wish to distribute offer discovery, offercuration, and offer redemption across multiple electronic devices andaccounts, with activities through one device or account being reflectedin other devices or accounts. Yet many traditional affiliate-networksystems are not configured to track these activities both on-line andoff-line (e.g., in-store or through a different device or account fromthat through which the publisher initially presented the offer). As aconsequence, these traditional systems are ill-suited to properlycompensate publishers, distribute offers through multiple on-line andoff-line channels, or provide merchants and publishers with analyticsand controls spanning multiple channels.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process, including: obtaining a coupon issued bya merchant, the coupon being redeemable both on-line, at the merchant'swebsite, and in-store, at a physical location of the merchant; sendingthe coupon to publishers for presentation to consumers by the publisherson user devices of the consumers; and receiving indications from theuser devices of the consumers that the consumers interacted with thecoupon, the indications indicating a consumer selection of an in-storeredemption option or an on-line redemption option. The process mayinclude, after an indication that a given consumer selected an in-storeredemption option, effectuating operations including: sending the givenconsumer in-store redemption data documenting that the given consumer isin possession of the coupon for presentation to the merchant at aphysical location of the merchant, the data identifying a firstpublisher that presented the coupon to the given consumer to creditfirst publisher; receiving transaction data from the merchant indicatingthat the given consumer redeemed the coupon; determining compensationfor the first publisher based on the transaction data. The process mayinclude, after an indication that another given consumer selected anon-line redemption option, effectuating operations including: storingon-line redemption data in memory documenting that the other givenconsumer selected the coupon and identifying a second publisher thatpresented the coupon to the other given consumer to credit thepublisher; and instructing the user device of the other given consumerto request content from the merchant's website. The process may furtherinclude obtaining the on-line redemption data stored in memory upon theother given consumer redeeming the coupon; and determining compensationfor the second publisher based on the obtained on-line redemption data.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by a data processing apparatuscause the data processing apparatus to perform operations including theabove-mentioned process.

Some aspects include a system, including: one or more processors; andmemory storing instructions that when executed by the processors causethe processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following FIGS. in which like numbers indicate similar oridentical elements:

FIG. 1 shows a computing environment having an example of anaffiliate-network system in accordance with some embodiments;

FIGS. 2 through 6 show an example of a process for distributing offersredeemable both on-line and off-line in accordance with someembodiments;

FIG. 7 shows an example of offer content that is dynamically configuredfor presentation on a user device having a relatively large display;

FIG. 8 shows an example of offer content that is dynamically configuredfor presentation on a mobile user device having a relatively smalldisplay;

FIG. 9 shows an example of a merchant-analytics interface that presentsdata aggregated across multiple channels of offer interaction;

FIGS. 10A and 10B each show portions of an example of apublisher-analytics interface that presents data aggregated acrossmultiple channels of offer interaction;

FIG. 11 shows an example of a process for dynamically adjusting theterms of multi-channel offers based on feedback from multiple channelsof offer interaction; and

FIG. 12 shows an example of a computing system by which theabove-mentioned systems, devices, and processes may be implemented.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit theinvention to the particular form disclosed, but to the contrary, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the present invention as definedby the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

FIG. 1 shows a computing environment 10 having an embodiment of anaffiliate-networking system 12. The illustrated system 12, in someimplementations, mitigates the above-mentioned problems with traditionalaffiliate-network systems, problems that, as noted, are particularlyacute when existing systems are applied to offers redeemable bothin-store and on-line. To mitigate these problems, the applicants had toboth invent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field.Indeed, applicants wish to emphasize the difficulty of recognizing thoseproblems that are nascent and will become much more apparent in thefuture should trends in the affiliate-networking industry continue asapplicants expect. Further, because multiple problems are addressed, itshould be understood that some embodiments are problem-specific, and notall embodiments address every problem with traditional systems describedherein. That said, solutions to many of these problems are describedwith reference the affiliate-networking system 12 of FIG. 1 .

In some embodiments, the affiliate-network system 12 is configured todistribute and track offers that are (for some offers) each redeemableon-line and off-line, which includes in-store redemption and redemptionthrough other devices or accounts:

-   -   a. To accommodate the different display capabilities of various        accounts and devices, some embodiments receive, from a merchant,        and implement specifications for an offer that define, at least        in part, how the offer is to be displayed in each of a variety        of different modes of presentation, such as on a desktop        computer web browser, on a tablet computer native application,        on a smart phone, in print, in email, and in short message        service text messages, to name a few examples.    -   b. To facilitate tracking, some embodiments host offer content        that publishers embed in their websites, native applications, or        other publisher content. In some cases, the offer content        returns to the affiliate-network system user interactions with        offers (e.g., selections of buttons and the like) that may be        tracked both when the user pursues on-line redemption and        off-line redemption.    -   c. To reduce the complexity of managing multi-channel offers for        merchants, publishers, and consumers, some embodiments store        data about an offer with reference to a single offer record,        such that multiple forms of interaction and presentation are        readily tracked, configured, or otherwise managed, with        reference to the single record.    -   d. To reduce complexity for those distributing offers, some        embodiments are configured to provide multi-channel access to an        offer through a single uniform resource identifier (URI)        corresponding to the offer, such that a request for offer        content identifying the URI (e.g., when a consumer's web browser        encounters the URI embedded in a publisher's website) yields        offer content configured according to the type of device or        account to which the offer content is directed. Using a single        URI for differently formatted presentation of an offer is        expected to simplify offer management for both consumers and        publishers, as format-specific URI need not be tracked by these        parties.    -   e. To facilitate tracking of multi-channel offers, some        embodiments are configured to provide analytics to both        merchants and publishers that aggregate both on-line and        off-line consumer interactions, such as redemptions.    -   f. To facilitate control of multi-channel offers, some        embodiments execute routines specified by merchants for        dynamically adjusting the terms of offers based on feedback from        multiple channels of offer redemption, including on-line and        in-store redemptions.

Thus, some embodiments of the affiliate-network system 12 address avariety of different problems associated with the use of offers that areredeemable both on-line and in-store. Each of these solutions, however,need not be included in every embodiment, as some embodiments mayaddress only some of the above-described problems with existingaffiliate-network systems, which is not to suggest that any otherfeature described herein may not also be omitted in some embodiments.

Operation of the affiliate-network system 12 is better understood inview of the other components of the computing environment 10 with whichthe system 12 interacts. As illustrated by FIG. 1 , embodiments includethe Internet 14, merchant systems 16, publisher servers 18, and consumeruser devices 20. The components of the computing environment 12 connectto one another through the Internet 14 and various other networks, insome cases, such as cellular networks, local area networks, wirelessarea networks, and the like. While three of each component 16, 18, and20 are illustrated, it should be understood that embodiments withsubstantially more of these devices are contemplated. For example,likely applications include tens of millions of consumer user devices20, tens of thousands of publisher servers 18, and hundreds or thousandsof merchant systems 16.

The illustrated merchant systems 16 may each correspond to a differentmerchant and may each include a variety of different types of computingdevices used by the respective merchants in the course of business.Merchant systems 16 may include merchant web servers that host merchantwebsites. In some cases, it is the merchant websites to which consumeruser devices 20 are directed for on-line redemption of offers and toview goods or services associated with offers. Merchant systems 16 mayalso include user devices of merchant employees that interact with theaffiliate-network system 12 to configure new offers, reconfigure.existing offers, view analytics associated with offers and publishers,and otherwise control offers issued by the respective merchant. Merchantsystems 16 may also include point-of-sale terminals and electronickiosks located at the physical sites of the respective merchant, such asat retail stores or service centers. Systems 16 may also includemerchant databases connected to those point-of-sale terminals forstoring financial-transaction records associated with transactions with,e.g., sales to, consumers. The merchant systems 16 may be configured toautomatically, or at the direction of the merchant's employees, uploadtransaction records from the merchant's database to theaffiliate-network system 12. These uploaded transaction records, in someembodiments, are used to determine compensation for publishers based onin-store redemptions of offers by consumers, the compensation rewardingpublishers who potentially made the consumers aware of the offers asindicated by records in the affiliate-network system 12. Often, merchantsystems 16 are geographically distributed, for example, havingpoint-of-sale terminals in multiple stores of a retail chain, and havinga merchant database and employee user devices in a central office of therespective merchant.

The publisher servers 18, in some embodiments, serve publisher content(e.g., web pages, data for display with a native application on a mobiledevice, set-top box, in-store kiosk, or the like). In some cases, thepublisher content is served to consumer user devices 20 and includesinstructions to retrieve and display offer content from theaffiliate-network system 12. In some cases, the offer content isembedded in the publisher's content, e.g., with URI's in a publisher'swebpage that cause a web browser to retrieve and embed content from theaffiliate-network system 12 bracketed with an HTML “embed” tag, ani-frame, or other instructions that cause content from outside thepublisher's domain to be displayed. In some cases, the offer content isnot embedded and is referenced by linking or re-directing to theaffiliate-network system 12. Or, in some cases, the publisher servers 18serve offer content directly to consumer user devices 20.

The publisher content, in some cases, is web content, like websiteshaving webpages in which multiple offers are referenced or included. Insome cases, consumers seek out the websites of publishers because thepublishers curate offers on behalf of the consumers (e.g., selectingoffers based on quality, success rate, subject matter, or the like).Publisher servers 18 may provide, in the publisher content, interfacesby which consumers can share data indicative of the efficacy orapplicability of offers, for example, by indicating success rates foroffers, providing content or comments about offers, rating offers,categorizing offers, or up-voting or down-voting offers. In other cases,the publishers servers 18 host content that is not specific to offers,such as webpages about particular areas of interest, like sportinggoods, electronic devices, home goods, fashion, current events, or thelike, and the publishers includes links to offers curated with thatpublisher's audience in mind.

In other cases, the publisher servers 18 host a publisher applicationprogram interface (API) that services native applications on consumeruser devices 20 (which may include public devices, like kiosks). Forexample, some publishers may offer a (non-web-browser) nativeapplication on a smart phone or tablet that is down-loadable from auser-device maker's service for providing approved applications.Examples of such applications include barcode-scanning applications bywhich a user captures an image of a product barcode with a camera of theconsumer user device 20, and the application converts the image into aproduct stock-keeping unit (SKU), which is then submitted to thepublisher server 18 for retrieving offers related to the SKU to bedisplayed on the consumer user device 20.

In another example, the application includes an application specificallyfor viewing offers. In some cases, the native application may beconfigured to interact with a user account hosted by the publisherserver 18 (which may include a plurality of computing devices, such as auser profile database and offers database) by which the user can viewoffers that they previously designated as favorites or view offers thatfriends of the offer user (e.g., as registered in a social network towhich the server has access) have identified to the offer user. Suchnative applications for viewing offers may further include various toolsby which the user can readily view and navigate through a plurality ofoffers, for example, including searching tools, faceted search, andlists of curated offers. In some cases, the native application isconfigured to obtain a geographic location of the user device, forexample, with a GPS sensor or other location determining serviceaccessed by the operating system of the consumer user device, andrequest offers based on the geographic location from the publisherserver 18, such as in-store offers for merchant stores that are near(e.g., within a threshold distance to or ranked based on a location of)the consumer user device. In some cases, the offers satisfy variousother criteria, for example, corresponding to a user profile indicatingthe types of offers in which the user is likely to be interested. Inother cases, a native application on the consumer user device may serveany of a variety of other functions for the consumer, and that nativeapplication presents offers as advertisements to subsidize the cost ofproviding that service.

The consumer user devices 20 may be any of a variety of different typesof computing devices through which consumers access the Internet 14.Examples of such computing devices are described below with reference toFIG. 12 . In some cases, a given consumer user device 20 is a smartphone, tablet computer, laptop computer, or desktop computer. Consumeruser devices 20 include a processor and memory and may execute anoperating system in which a web browser or native application executesfor viewing offers. In some cases, the consumer user device 20 is amobile user device, which includes a portable power supply, like abattery, a fuel cell, or a solar energy source, such that the consumercan carry the user device into a merchant's physical store for in-storeredemption. In some cases, such mobile user devices include a wirelessinterface, such as Bluetooth™, a near-field communication (NFC)interface, or a wireless area network interface, by which the consumeruser device exchanges information with the point-of-sale terminal aboutoffers being redeemed, such as an offer identifier. Further, in somecases, the mobile user device includes a display by which an identifierof the offer to be redeemed is presented and is entered into apoint-of-sale terminal, for instance, by a sales clerk viewing thedisplay and manually typing in the offer identifier (e.g., an offercode), or by the sales clerk scanning the display with a barcode scanneror an optical scanner. In other cases, the consumer user device is notmobile and includes a relatively large display, for example, a desktopcomputer or a set-top box connected to a television with a screen largerthan 10-inches measured diagonally. In some cases, consumer user devices20 include an application specifically for viewing offers (e.g., anative application executing on a set-top box, like a gaming console orstreaming media device) or include a web browser by which the usernavigates to a publisher's website for viewing offers and to amerchant's website for redeeming offers. Consumer user devices 20 may beany of a variety of types of electronic devices connected to theInternet 14 by which users are made aware of, store, or obtaininformation about offers, including smart watches, head-mounteddisplays, networked appliances (e.g., Internet-enabled refrigerators),or public computing devices, such as an in-store kiosk.

As noted above, in some cases, offer content viewed on consumer userdevices 20 is identified to consumers by publisher servers 18, but ishosted by the affiliate-network system 12. For example, publisherservers 18 may send consumer user devices 20 a webpage listing aplurality of offers, and each offer listing may include an instructionto the consumer user device 20 to retrieve offer content from theaffiliate-network system 12 corresponding to the offer, for example, aURI of the respective offer that directs the consumer user device 20 toretrieve content from the affiliate-network system 12. Offer content mayinclude various offer resources by which views of offers areconstructed, such as mark-up information, templates, images, offerterms, coupon codes, and interfaces for interacting with the offer(e.g., buttons and scripts executed when buttons are selected toeffectuate selected actions). The offer content may be hosted by theaffiliate-network system 12, rather than the publisher server 18, tofacilitate tracking of offer interactions (e.g., redemptions, sharing,printing, or sending to another device or account) across both on-lineand off-line redemption channels. Or, some embodiments host the offercontent on the publisher servers 18 instead of, or in addition to, theaffiliate-network system 12.

Thus, in some cases, the display of an offer on a consumer user device20 may be preceded by the consumer user device 20 requesting contentfrom the publisher server 18, receiving that content, determining thatthe content includes instructions to request offer content from theaffiliate-network system 12 on a different domain from the publisherserver 18, and executing those instructions, to retrieve the offercontent. In some cases, the instructions from the publisher server 18 torequest offer content do not specify the type of user device or type ofaccount in which the offer will be viewed. Rather, in some embodiments,a single instruction, such as a single URI per offer, is provided by thepublisher server 18 regardless of the type of consumer user device orthe account, thereby relieving publishers of the burden of maintainingmultiple, different instructions for a single offer for each of thevarious potential viewing options. In response, the consumer user device20 may request content according to this instruction, for example withthe URI. In response, the affiliate-network system 12 may determinebased on the request and, in some cases, additional information aboutthe consumer user device 20 or account, the appropriate offer contentfor the type of presentation in which the offer will be viewed orotherwise used.

In some embodiments, the affiliate-network system 12 includes a webserver 22, an API server 24, a controller 26, an affiliate-network datastore 28, a content-negotiation module 30, a dynamic-terms offercontroller 32, and an analytics module 34. These components areillustrated and described as discrete functional blocks, but it shouldbe understood that code or hardware by which this functionality isprovided may be subdivided, intermingled, conjoined, or otherwisedifferently arranged. Further, it should be understood that one or morecomputing devices, and in many embodiments, a plurality of computingdevices, by which this functionality is implemented may begeographically distributed or co-located, for example, in a dataprocessing facility. Further, it should be understood that some of thecomponents and features of the affiliate-network system 12 may beomitted in some embodiments, which is not to suggest that any otherfeature is required in all embodiments.

In some embodiments, the web server 22 is operative to receive requestsfrom web browsers executed by user devices of consumers, publishers, ormerchants. In some cases, those requests include requests for, orinteractions with, role-specific webpages, for consumers, publishers, ormerchants. For instance, a merchant may request a webpage for specifyinga new offer, viewing data about a previously specified offer, oradjusting attributes of an existing offer. In another example, the webserver 22 may include code for providing a webpage with interfaces bywhich merchants create a new merchant account, view data about amerchant account, or adjust attributes of a merchant account. Similarly,the web server 22 may include code for providing a webpage withinterfaces for specifying a publisher account, viewing a publisheraccount, or adjusting a publisher account. In some cases, theseinterfaces include buttons that when selected cause client-side scriptsto communicate with web-server 22. Other example interfaces include textboxes, radio buttons, check boxes, and the like for data entry. Browsersexecuting on user devices may submit entered data and commands to theweb server 22, which may advance the commands to the controller 26 forresponsive action by the affiliate-network system 12. Similarly, the webserver 22 may receive requests for resources from such user devices, forexample, to form the corresponding webpages, and the web server 22 mayadvance requests for responsive content to the controller 26 forretrieving and returning the responsive content.

The API server 24, in some cases, may be configured to supportprogrammatic interaction with the affiliate-network system 12 throughprograms (e.g., non-web-browser programs) executing on the publisherservers 18, the merchant system 16, or consumer user devices 20. The APIserver 24 may support a variety of commands to manipulate or retrievedata from the affiliate-network data store 28, examples of which aredescribed throughout this document. In some cases, the API server 24 maybe operative to receive a request for offers from a publisher server 18and advance that request to the controller 26 which retrieves responsiveoffers from the affiliate-network data store 28. The API server 24 mayreturn those offers to the publisher's server 18 from which the requestwas received. In some cases, the request specifies various criteria ofthe offers, such as geographic criteria, a category of offers, a type ofredemption, a merchant, a category of merchant, or other offerattributes, and the API server 24 instructs the controller 26 toretrieve responsive offers satisfying the criteria. Similar requests maybe received from the merchant system 16 or the user devices 20,depending upon the application. In some cases, the API server 24 isoperative to receive and initiate responses to publisher or merchantrequests for role-specific analytics, such as data for reports providedby the analytics module 34 described below. Other interfaces supportedby the API server 24 may include, in some embodiments, uploadfunctionality, by which merchants upload new offers programmatically,change offers programmatically, or upload transaction data describingin-store redemptions of offers. Similarly, in some cases, publishers mayupload information about user interactions with the offersprogrammatically, or consumer user devices 20 may upload informationabout consumers or consumer interactions with offers programmatically,provided that the consumer has opted in to the appropriate privacysettings allowing such uploads.

In some embodiments, the controller 26 is operative to receive commandsand data from the web server 22 or the API server 24 and coordinateresponsive actions by the other components of the affiliate-networksystem 12. Examples of activities coordinated by the controller 26 aredescribed below with reference to FIGS. 2 through 6 . In some cases, thecontroller 26 is operative to translate web requests or API requestsinto corresponding data transformations and database interactions tostore or retrieve implicated data.

In some embodiments, the affiliate-network data store 28 stores dataabout merchants, publishers, offers, and consumer interactions withoffers. The affiliate-network data store 28, in some cases, is arelational database, or other types of data stores may be used,including hierarchical key-value stores, program state, and memoryimages. In this embodiment, the affiliate-network data store 28 includesa merchant data store 36, a publisher data store 38, an offer data store40, and a tracking data store 42. In some cases, each of these datastores 36, 38, 40, and 42 may be separate databases or, in other cases,these data stores may be intermingled in a single database or other datastore. The affiliate-network data store 28 may be operative topersistently store data about merchants, publishers, offers, andconsumer interactions with those offers. In some cases, theaffiliate-network data store 28 is configured to receive queries, forexample, submitted in the form of structured query language fromcontroller 26 and respond with responsive data. Similarly, theaffiliate-network data store 28 may be responsive to commands fromcontroller 26 to store data or delete data, e.g., when creating newrecords or changing records.

In some embodiments, the merchant data store 36 is configured to storedata about merchants that use the affiliate-network system 12 todistribute offers and track interactions with those offers. In someimplementations, the merchant data store 36 stores a plurality ofmerchant records, each merchant record corresponding to a differentmerchant account with the affiliate-networking system, and in somecases, corresponding to a different merchant. In some cases, eachmerchant record includes the following data: a trade name of themerchant; a business-entity name of the merchant; a unique merchantidentifier by which the merchant record may be linked to other recordsin the affiliate-network data store 28; merchant-specific brandingcontent (such as images of the merchant's logo at various resolutions,merchant tag-lines, merchant website URLs, or URIs of such content) foruse in the merchant's offer content; analytics tags (examples ofanalytics tags include code or resources, like a tracking pixel, to beadded to offer content, like an offer page, corresponding to therespective merchant's analytics system (e.g., Omniture provided by AdobeSystems, Inc. of San Jose, Calif., or Google Analytics provided byGoogle Inc. of Mountain View Calif., among others) that cause the userdevice to provide information with the merchant's analytics system,thereby allowing the merchant to measure performance of the offercontent as if it was part of their own website or mobile application);geographic merchant locations (e.g., a plurality of site records, eachsite record corresponding to a brick-and-mortar site and having alocation—like a street addresses of the store, latitude and longitudecoordinates of the store, or coordinates of a polygon bounding thestore—along with store hours, point-of-sale capabilities—like barcodescanning, optical scanning, and NFC capabilities that may be used toexchange data with consumer user devices during an in-store couponredemption—and various merchant-defined categories) for selecting offersbased on location or store-specific attributes; merchant categories(e.g., sporting goods, financial services, retail clothing, and thelike) for selecting offers based on merchant specialty; supported couponcode formats (e.g., whether the merchant supports single-use couponcodes that are unique to a customer or customer session with a publisheror other coupon provider, or whether the merchant supports multi-usecoupon codes that are widely distributed to multiple users) fordetermining offer configuration options for a merchant; merchant contactinformation (e.g., a plurality of employee records, each record having aname, password, role, phone number, email address, and permissions tointeract with the affiliate-network system 12 on behalf of the merchant)to facilitate controlled distribution of offers by authorized employeesof the merchant; and pre-approved publishers (e.g., publisheridentifiers corresponding to records in the publisher data store 38 thathave been whitelisted or blacklisted by the merchant, or a category ofpublishers that have been whitelisted or blacklisted) to facilitateefforts by merchants to limit distribution of their offers to publishersthat are consistent with the merchant's brand.

In some embodiments, the publisher data store 38 is configured to storedata about publishers that interact with the affiliate-network system 12to distribute offers. The publisher data store 38 may include aplurality of publisher records, each publisher record corresponding toone publisher account, and in some cases, a different publisher. Eachpublisher record may include the following data: a publisher trade name;a publisher business-entity name; a publisher identifier that is uniqueto the publisher record in the affiliate-network system 12 and is usedto link the publisher record to other records within theaffiliate-network data store 28; a publisher category (e.g., nominalvalues in a taxonomy of publishers, such as those identifying sports orfashion-related publications); publisher-specific content and resources(e.g., images of the logo of the publisher at various resolutions,publisher-selected settings to configure the visual presentation ofoffers distributed by that publisher—such as settings defining apublisher's color scheme and indicating which colors are mapped to whichoffer presentation elements, like buttons, headers, and the like, apublisher's font selection, and various cascading style sheet settingsdefined by the publisher—as well as a publisher's contact informationfor consumers—like a web address of a help webpage or FAQ webpage hostedby the publisher, and various other links to other portions of thepublishers website, such as a homepage of the publisher, or URIs of suchpublisher content or resources) to configure offer presentation from theaffiliate-network system 12 in a manner that is consistent with thepublisher's brand; publisher analytics tags (e.g., like those describedabove with respect to merchants except tied to a publisher's analyticssystem); publisher metrics (e.g., audience size as measured by pageviews, unique page views, number of publisher mobile device applicationinstalls, or audience demographics, including geographic distribution ofthe audience, income of the audience, education level of the audience,interests of the audience, occupations of the audience, and variousother statistics characterizing the publisher's audience) to facilitateselection of publishers by merchants according to the publishersaudience; distribution channels of the publisher (e.g., publisherwebsites, mobile device native applications, set-top box applications,and various other programs for displaying and interacting with publishercontent on consumer user devices) to facilitate selections of publishersby distribution channel or selections of distribution channels bymerchants; publisher geolocation capabilities (e.g., values indicatingwhether the publisher is capable of obtaining a user geolocation from alocation sensor on a mobile phone, Internet Protocol addressgeolocation, or a user profile maintained with the publisher) tofacilitate selection of publishers by merchants according to theexpected reliability and existence of geolocation information; otherconsumer user device interfaces to which the publisher has access (e.g.,values indicating whether the publisher operates a native applicationconfigured to access a camera of the consumer user device, a microphoneof the consumer user device, a near-field communication interface of theconsumer user device, a Bluetooth™ user interface of the consumer userdevice, or other such wireless interfaces) to facilitate selection ofpublishers by merchants according to these capabilities; and publishercontact information (e.g. a plurality of employee records, each having aname, password, role, phone number, email address, permissions tointeract with the affiliate-network system 12, and the like of variousemployees of the publisher).

In some embodiments, the offer data store 40 is configured to store dataabout offers issued by merchants for distribution by publishers. Theoffer data store 40 may store a plurality of offer records, each offerrecord corresponding to a different offer by a merchant. In someembodiments, each offer record includes the following data: an offeridentifier unique within the affiliate-network system 12 and used tolink the offer record to other records in the affiliate-network datastore 28; a merchant identifier indicating the merchant issuing theoffer and linking to one of the merchant records in the merchant datastore 36; an offer title to be included as part of offer contentdisplayed on consumer user devices when displaying the offer; a startdate of the offer indicating the date or time upon which the offerbecomes valid for redemption; an expiration date indicating the date ortime upon which the offer ceases to be valid and can no longer beredeemed; a publication date indicating the date or time upon which theoffer is available for publishing by publishers; a publication finishdate indicating the date or time upon which the offer will cease to beavailable for publishing; an offer type (e.g., a nominal valueindicating whether the offer is a coupon, a sale, a rebate, an offer fordiscounted shipping, or the like) to facilitate filtering of offers byoffer type by publishers or consumers; an offer tracking type (e.g., aBoolean value indicating whether the offer is being tracked, or anominal value indicating a type of tracking); an offer monetization type(e.g., a Boolean value indicating whether the offer is being monetized(e.g., whether the merchant is compensating the operator of theaffiliate-network system 12 for distributing the offer, such as a flatfee, a percent commission, or a cost-per-click reward); a commissiontype (e.g., a nominal value indicating whether commissions to publishersare based on a per-interaction rate, a per-redemption rate, aper-impression rate, or the like); a commission rate (e.g., a percentageor dollar amount); an offer description (e.g., a prose description ofthe offer to be sent to consumer user devices 20 when displaying theoffer); offer rules (e.g., a condensed, consumer-friendly prosedescription of relatively significant terms and conditions, such asthose limiting the offer to particular brands or highlighting anexpiration date, for use when displaying the offer); offer terms andconditions (e.g., a relatively comprehensive prose description of termsand conditions provided by the merchant and defining the terms of theoffer, which may be presented in response to a user selection of aninterface in the offer content to request the terms and conditions); astore applicability type of the offer (e.g., a Boolean value indicatingwhether the offer is applicable across a store with no brand or categoryrestrictions, or a nominal value indicating the absence or presence ofvarious types of such restrictions); a domain, publisher, or publishercategory whitelist or blacklist of the offer to facilitate fine-grainedpublisher-by-publisher distribution of subsets of offers by merchants;offer user-interaction limits (e.g., key-value pairs listing a userinteraction type, such as printing, sharing in a social network, sendingto a text message, or combinations of such interactions, and a limit onthe number of permitted interactions for the offer, such as a limitednumber of times the offer may be printed, shared, sent to a textmessage, sent to a card-linked offer account, sent to an email account,saved to a clipboard memory of the consumer user device, or sent to anelectronic wallet, or combinations thereof, including the aggregate ofall interactions) to facilitate efforts by merchants to control thenumber of redemptions of offers; an offer redemption type (e.g., a listof nominal values indicating the channels through which the offer isredeemable, such as on mobile devices, by printing, by printing from amobile device, across all channels, or a listing of particular mobiledevice applications, accepted card-linked offer account providers,electronic wallet providers, or the like that constitute a whitelist orblacklist of channels through which the offer is redeemable or notredeemable) to facilitate efforts by merchants to establish exclusiverelationships with providers of such accounts and favor particular typesof redemption channels through which offers are believed by merchants tobe more effective; an in-store redemption indicator (e.g., a Booleanvalue indicating whether the offer is valid for in-store redemption bypresentation of, for example, a coupon code or offer barcode, by aconsumer to a clerk at a point-of-sale terminal) to again facilitateefforts by merchants to control redemption channels to those believed tobe effective for the particular offer; a percentage discount of theoffer (e.g., 20% off the base price of some good or service) tofacilitate offer curation by publishers and consumers according to theamount of the discount and for display on the consumer user device whendisplaying the offer; a percentage-up-to value indicating whether someapplicable discounts supported by the offer are less than the percentageoff value; a minimum purchase value (e.g., a minimum purchase amount indollars or number of goods or services required to receive thepercentage off discount of the offer) for offer filtering and display; adollar amount off from the offer (e.g., five dollars off the price ofsome good or service) for offer filtering and display; a dollar-up-toamount indicating whether some applicable discounts from the offer areless than the dollar amount off; a minimum-dollar-purchase amountindicating the amount required to be purchased to activate the offer'sdollar amount off discount; a Boolean value indicating whether the offerincludes a free gift; a prose description of a free gift item; a freeshipping Boolean value indicating whether the offer is associated withfree shipping of goods; a free-shipping minimum-purchase amountindicating the minimum amount that the consumer must purchase to receivefree shipping; a free-gift minimum purchase indicating the minimumpurchase required to receive the free gift; a buy-X-get-Y-free key-valuepair indicating how many free items are offered for a number of itemspurchased (e.g., buy one get one free); a by-X-get-Y-free minimumpurchase indicating the minimum amount to be purchased to activate theoffer for buy-X-get-Y-free key-value pairs; and a category of the offer(e.g., a single-level taxonomy of offers, or a hierarchical taxonomy ofoffers, such as retail/sporting goods/golf equipment) to facilitateoffer filtering and selection by consumers and publishers.

In some embodiments, the tracking data store 42 is configured to storedata about interactions with offers, such interactions includingin-store redemptions, on-line redemptions, interactions requesting thatoffer be sent to another consumer user device, or another consumeraccount (e.g., a card-linked offer account, an electronic walletaccount, an email account, a social networking account, or the like). Insome cases, the tracking data store 42 includes a plurality ofoffer-tracking records, each offer-tracking record corresponding to adifferent instance of interaction with an offer (e.g., a given consumer,requesting a printable view of a given offer and that consumerpresenting the printout at a point-of-sale to redeem the offer wouldconstitute two records). In some embodiments, each offer-tracking recordincludes the following data: an interaction identifier unique within theaffiliate-network system 12 and by which offer interactions are linkedwith other records within the affiliate-network system 12; an identifierof an offer to which the interaction relates (e.g., an identifier of oneof the offer records in the offer data store 40); a publisher identifierindicating the publisher to be credited with the interaction (e.g., anidentifier of one of the publisher records in the publisher data store38 identifying a publisher that distributed the offer to a consumer userdevice 20 through which the interaction occurred); related interactions(e.g., identifiers of earlier interactions potentially causally relatedto the interaction record, such as a print interaction that lead to anin-store redemption interaction, or a social-network sharing interactionthat lead to an on-line redemption interaction by the recipient); aconsumer user device identifier that identifies the consumer user device20 upon which, or through which, the interaction occurred (e.g., amedium access control (MAC) address of the consumer user device, anadvertiser identifier associated with the device, or other deviceidentifier); an identifier of a consumer associated with the consumeruser device upon which, or through which, the interaction occurred(e.g., an identifier of a user profile account having information aboutthe user that interacted with the offer, such as name, address, offerpreferences, and the like); an identifier of a session during which theinteraction occurred; an identifier of an interaction-specific offercode (e.g., a single-use code dynamically generated when presenting theoffer and that when presented for redemption, either in-store oron-line, identifies (e.g., uniquely) the corresponding interactionrecord); a publisher-specific offer code (e.g., an offer code for agiven publisher that facilitated the interaction and that uniquelyidentifies the publisher when the offer is presented for redemption); aninteraction type (e.g., a nominal value indicating on-line redemption,in-store redemption with a coupon code, in-store redemption by mobiledevice screen, in-store redemption by mobile device display, in-storeredemption by mobile device wireless interaction with a point-of-saleterminal, in-store redemption with a printed copy of the offer, on-lineor in-store redemption with a card-linked offer account, on-line orin-store redemption with an electronic wallet account, or the like); aninteraction location indicating, to the extent known, a geographiclocation at which the interaction occurred (e.g., an identifier of amerchant's physical store, a geocoded IP address of a consumer userdevice used in the interaction, a location sensed by a location sensorin the consumer user device, or the like); a time of the interaction(e.g., a time stamp); a merchant associated with the interaction (e.g.,a merchant through which the offer was redeemed, which in some cases maybe different from the merchant that issued the offer, for example, foroffers issued by brands redeemable at various retail stores); aninventory of goods or services purchased during the interaction (e.g., aplurality of transaction records listing items purchased andcorresponding purchase amounts for calculating an aggregate value forthe transaction upon which publishers are compensated in some cases); atransaction currency; and a consumer-user-device type of the device uponwhich the interaction occurred or was facilitated (e.g., an indicator ofwhether the consumer user device is a cell phone, tablet, personalcomputer, laptop, set-top box, in-dash automotive computer, a wearablecomputing device, or identifying a maker or software provider for thedevice).

Such fine-grained transaction data is expected to facilitate relativelyreliable compensation of publishers by merchants, aligning the interestsof the two groups, and relatively high-resolution analytics of consumeractivity for improving the design of offers and publisher content. Forinstance, some merchants may compensate publishers for offers beingprinted or sent to another device even when the ultimate redemption ofthe offer in-store is not recorded by an interaction record. Often, whenusing traditional affiliate-network systems, in-store sales clerks willscan an offer barcode from a printout at their register, rather thanscanning the barcode presented by the consumer, because doing so is asimpler and repetitive action, but in doing so, the publisher ispotentially denied credit they might otherwise obtain from scanning apublisher-specific or single-use bar code on the printout our consumeruser device display. Tracking printing and various transfers of offersbetween devices and accounts offers merchants a supplemental metric fordetermining publisher compensation and encouraging desirable publisherefforts to distribute offers.

Thus, the affiliate-network data store 28 may store values related tothe provision and tracking of offers on-line and in stores. Theaffiliate-network data store 28 may be operative to filter, search,join, sort, augment, create, delete, modify, and search theabove-mentioned records in a variety of permutations of subsets of therecords. It should be noted that not all embodiments include all of thefields discussed above with reference to the affiliate-network datastore 28 and that some embodiments store additional fields or use theabove-mentioned fields for different purposes than are described, whichis not to suggest that any other feature described herein may not alsobe omitted or used in a different fashion than is described.

In some embodiments, the content-negotiation module 30 is configured todynamically format offer content according to the manner in which offerswill be displayed to a consumer. In some embodiments, each offer isassociated with an offer-specific URI (e.g., a uniform resource name(URN) or locater (URL)) that corresponds to multiple presentationformats of the offer appropriate for different devices or accounts. (Andin some cases, the URI is both offer specific and publisher specific, asexplained below.) The content-negotiation module 30 may be configured toform (e.g., select among or dynamically generate) these presentationformats based on attributes of the consumer user device 20 upon whichthe offer will be displayed or (i.e., and/or) attributes of an accountthrough which the offer will be conveyed to a user (e.g., an emailaccount, a social networking account, a card-linked offer account, or anelectronic wallet account).

To this end, the content-negotiation station module 30 may be configuredto receive data about the type of presentation (e.g., device attributesor account attributes) with a variety of different techniques. In somecases, a request from a consumer user device 20 to the affiliate-networksystem 12 for offer content corresponding to a URI includes user agentinformation about the consumer user device 20, such as a user agentstring in a header of a request specified by a transport protocol (e.g.,HTTP or SPDY). In some cases, the user agent information may be includedwith a get request under the transport protocol for resources at theURI. User agent information may include an identifier of a web browser,an operating system, a listing of accepted media types, supportedcharacter sets, encodings, languages, and the like. In some cases, therequest for content at the offer URI includes information about themanner in which the offer will be displayed, for example, a screen sizeexpressed in resolution or absolute geometric dimensions, a window sizeexpressed in pixels or geometric dimensions, color capabilities,three-dimensional capabilities, and the like. In some cases, the requestindicates whether the offer will be displayed on a printout from aprinter, or whether the offer will be displayed in a particular type ofaccount, such as those listed above.

In some cases, the request is not a sufficiently-specified descriptionof how the offer will be displayed, and the content-negotiation module30 may send instructions to the requesting consumer user device 20 tofurther identify such attributes, such as JavaScript™ that when executedreturns a window size, a screen resolution, and i-frame size, a div-boxsize, a document-object-model (DOM) element size, or the like, withinwhich the responsive offer content will be displayed. The code, whenexecuted in a web-browser of a consumer user device 20, may return thecorresponding parameters to the content negotiation module 30. In somecases, the request is from a native application executing on a consumeruser device 20, and the request is received via the API server 24. AnAPI of the affiliate-network system 12 may specify that requests includethe above-mentioned information about the consumer user device 20 oraccount, or embodiments may send a default format of offer content whensuch information is unavailable.

In some embodiments, the content-negotiation module 30 is configured toretrieve the appropriate offer content for the URI (e.g., offerresources, like prose descriptions and images, and instructions fordisplaying the resources and, in some cases, for providingoffer-selection interfaces for a given offer) based on the dataindicating how the offer will be displayed. For example, thecontent-negotiation module 30 may receive data indicating that the offerwill be displayed on a mobile phone, tablet, laptop, or desktop computerin a web browser, email account, text message, social networkingaccount, card-linked offer account, electronic wallet account, or thelike. In response, the module 30 may form (e.g., select or generate) anoffer presentation template corresponding to one of these types ofpresentation. Thus, some embodiments of the content-negotiation module30 may store in memory a plurality of different offer presentationtemplates, each template corresponding to a different type of consumeruser device, presentation environment on a consumer user device, oraccount through which the offer will be presented to a user. Or in somecases, some or all of the offer templates are dynamically generatedaccording to the type of presentation, for example, dynamically scalingdimensions, image resolutions, and font sizes with the size of thedisplay of the consumer user device 20 or size of a window or DOMelement in which the offer content will be shown.

An offer template, in some cases, specifies text to be included in offercontent, for example, specifying the inclusion of more expansive prosedescriptions of offers in templates for larger display screens oraccounts in which longer bodies of text are appropriate (like in email,as opposed to text messages). In some cases, shorter and longer versionof offer descriptions are maintained in the offer records for thispurpose. Similarly, offer templates may specify larger fonts,higher-resolution images, and more images, in templates for largerdisplay screens or for accounts configured to accommodate richercontent. Thus, the offer templates may include instructions to retrieveand display various offer-related resources, such as a merchant logo, anoffer-specific image, a prose description of the offer, and adescription of various terms and conditions of the offer. In some cases,various versions of the offer content are maintained in the offer datastore 40, such as lower and higher resolution versions of images, andmore concise and less concise versions of text, and the offer templatesmay specify these different versions depending upon the type ofpresentation to the consumer.

Offer template selection may also depend upon the potential use of aconsumer user device 20 for in-store redemptions (e.g., templates maydiffer for mobile phones and desktop computers to account for thepotential presentation of the mobile device in-store). In someimplementation, templates for printing offers (e.g., those that provideprintable views of offers in black-and-white and are sized for A4 paper)may include a barcode image (or QR code, or the like) that can bescanned at a point-of-sale terminal for redeeming an offer. Templatesfor use on mobile user devices may include such images as well (e.g., byspecifying that when the template is populated for a given offer, abarcode image for that offer is generated or retrieved and added tooffer content formed based on the template). Images foroptically-machine-readable codes, like barcodes and QR codes, may beincluded in (e.g., linked to with a URI) the above-mentioned offerrecords. Or some embodiments may generate publisher-specific,user-specific, or session-specific optically-machine-readable codes thatuniquely identify one of these items. The code may be associated with apublisher record, a user profile, or an interaction record, depending onthe application, and after the code is scanned at a point-of-saleterminal, the respective item (e.g., publisher record, user profile, orinteraction record) may be associated with the transaction at thepoint-of-sale terminal to track publisher, user, and offer metrics.

In some cases, the offer templates include (e.g., specify, in part, howto form) interfaces by which a user further interacts with offers.Examples of such interfaces include on-screen buttons that, whenselected (e.g., by touching or clicking), launch a client-side script orroutine that issues a request from the consumer user device to theaffiliate-network system 12 for a different presentation of the offer,such as a printable view. With a similar process, other includedinterfaces (e.g., buttons, voice commands, or gestures) may indicatethat the offer should be sent to another consumer user device 20 oraccount, such as a button to launch an interface for entering a phonenumber to which offer content is texted or an email account to which anemail version of offer content is sent. In some cases, the set ofinterfaces are different for the different templates.

In some cases, the offer templates include publisher-specific attributesof offer content that are formed (e.g., selected or generated) based onthe identity of the publisher that advanced the URI to a consumer userdevice 20 (which then requests corresponding offer content from theaffiliate-network system 12). To this end, in some embodiments, thecontent-negotiation module 30 may parse from the request for offercontent an identifier of a publisher, and the module 30 may retrieveinformation for populating the template based on publisher-specificcontent, such as images and other attributes like colors, fonts, links,and text. For example, offer content may include one or more on-screenbuttons, and an offer template may specify a publisher-button-colorfield for determining the button color. In response, when populatingthis template for a URI advanced by a given publisher, thecontent-negotiation module 30 may retrieve from the publisher data store38 that publisher's selection of a color of the button and form offercontent in accordance with the selection. Similar fields may specifyother aspects of offer content. Thus, in some embodiments, differentpublishers may direct consumers to the same offer with different colors,publisher logos, publisher's terms of use, links to other publishercontent, links to publisher help webpages, and the like.

In short, the content-negotiation module 30 customizes offer contentbased on context. In some embodiments, the visual depiction of an offermay depend on the attributes of the consumer user device 20 upon whichthe offer will be displayed, the type of account through which the offeris presented, and the publisher from which the consumer user device 20received the URI of the offer. The content-negotiation module 30 maypopulate the templates based on responsive resources and sendinstructions to the consumer user device 20 to display the offercontent.

In some embodiments, the affiliate-network system 12 includes adynamic-terms offer controller 32 that dynamically adjusts the terms ofoffers (e.g., types of redemption, expiration date, start date, percentdiscount, and the like) based on feedback from the tracking data store42, which may indicate both an amount of on-line redemption activity andoff-line (such as in-store) redemption activity. Some embodiments of thedynamic-terms offer controller 32 perform a process described below withreference to FIG. 11 . The affiliate-network system 12, as noted above,tracks offer interactions across multiple channels. A benefit of thisapproach is that offers can be dynamically controlled relativelyreliability based on relatively comprehensive accounting of offer usageor likely usage. (Though, not all embodiments necessarily provide thesebenefits.) For instance, a merchant may specify that the percentdiscount of an offer is to decrease by some amount (or the offer is toexpire) automatically in response to the aggregate of on-line andoff-line interactions exceeding a threshold rate or amount, therebyconstraining offers that have spread more widely than anticipated orpotentially specify a greater discount than the merchant intended tooffer due to a data entry error. In some cases, these thresholds are setautomatically, for instance at five standard deviations of an aggregaterate (e.g., a daily average) of accumulation of offer interactionrecords for offers for a given merchant, and alerts are issued to themerchant in response to the threshold being exceeded so that themerchant can manually intervene and terminate or adjust an offer ifneeded.

In some embodiments, the affiliate-network system 12 further includesthe analytics module 34, which may be configured to query data from thetracking data store 42 and present role-specific reports to publishers,merchants, and administrators of the affiliate-network system 12.Examples of reports are described below with reference to FIGS. 9 and 10. The analytic s module 34 may be operative to receive a request forsuch a report specifying various criteria, such as a merchant account ora publisher account, query the tracking data store 42 for the responsivedata, and generate visual depictions of the data, such as thosedescribed below. Reports that account for both on-line and off-lineinteractions with offers are expected to simplify the process ofmonitoring and analyzing offers that are redeemable through multiplechannels, an undertaking which can be relatively arduous withtraditional affiliate-network systems, particularly for merchantsissuing hundreds of new offers each day. (Though, again, not allembodiments necessarily provide this benefit.)

Some embodiments of the affiliate-network system 12 implement techniquesto protect user privacy, for example, anonymizing identifiers ofconsumer user devices 20 by hashing information from the consumer userdevices 20, reducing the granularity of attributes recorded inassociation with user interactions (like rounding less significantdigits of latitude and longitude coordinates), and providingprivacy-controls by which consumers or publishers can implement userprivacy-preferences.

In summary, the affiliate-network system 12, in some embodiments, isoperative to coordinate activities relating to offers by web-scalenumbers of consumer user devices 20, merchant systems 16, and publishers18, which may implicate potentially hundreds of thousands or millions ofoffers, some of which may be dynamically adjusted with terms that changeover time, some of which may have visual depictions that are dynamicallyadjusted, and some of which may have single-use offer tracking codescorresponding to an individual consumer interactions with offers. Toaccommodate operations at these scales, in some cases, theaffiliate-network system 12 may include a relatively large number ofgeographically distributed networked computing devices and employvarious techniques to speed operation, such as use of elastic scaling ofthe system 12 and use of content-delivery networks.

FIGS. 2 through 6 are a flowchart showing an embodiment of a process 44for distributing offers both on-line and off-line (e.g., in-store orthrough multiple devices or accounts). Some embodiments of process 44are performed with the affiliate-network system 12 described above,though it should be noted that embodiments are not limited to theparticular features of that system 12. The flow charts of FIGS. 2through 6 are arranged in four columns, each column corresponding to therole of a different entity and associated computing hardware performingparts of the process 44. In other embodiments, the various roles of thedifferent entities may be arranged differently, for example, themerchant may operate the affiliate-network system, the affiliate-networksystem and the publisher server may be operated by the same entity, orthe merchant system, affiliate-network systems, and the publisher servermay all be part of the same system operated by the same entity,depending upon the arrangement. Embodiments of the process 44 may beeffectuated by one or more data processing apparatuses, examples ofwhich are described below with reference to FIG. 12 , executinginstructions stored on a tangible, non-transitory, machine-readablemedium, such as various forms of computer memory like, dynamic randomaccess memory and persistent storage in the form of hard drives oroptical media.

The process 44, in some embodiments, describes the life-cycle of anexemplary offer, beginning with the creation of accounts of merchantsand publishers, followed by the offer being defined by the merchant, anaffiliate-network system distributing the offer to the publishers, thepublisher making a consumer aware of the offer, the consumer redeemingthe offer either in-store or on-line, and arrangements being made forcompensation of the publisher by the merchant based on tracking of theoffer redemption or other interactions with the offer. Like the otherembodiments described herein, various portions of the process 44 aredirected to different problems with existing affiliate-network systems,such as those described above, and as such, subsets of the process 44are expected to be independently useful, which is not to suggest thatany other features described herein cannot also be omitted in someembodiments.

In some embodiments, the process 44 begins with the merchant systemsending merchant parameters to the affiliate-network system, and theaffiliate-network system adding those merchant parameters to a merchantdata store, as indicated by blocks 46 and 48 in FIG. 2 . The merchantparameters may include some or all of the fields in the merchant recordsdescribed above with reference to the merchant data store 36 of FIG. 1 .In some cases, the merchant parameters are provided through a websiteinterface hosted by the affiliate-network system. This website mayinclude interfaces by which a merchant can populate a merchant record(or an administrator of the affiliate-network system may enter thoseparameters on behalf of the merchant). The merchant system may includean employee's user device by which the employee provides the merchantparameters via email or a via a web browser, in some cases. In some usecases, the merchant parameters define a merchant account with associatedmerchant employee accounts with usernames and passwords for grantingvarious levels of access to merchant employees based on the amount ofauthority granted by the merchant to those employees. The merchantparameters may be stored in one of the above-mentioned merchant records,and a unique merchant identifier may be created for the merchant recordto distinguish the merchant record from those of other merchants.

Next, in some embodiments, the merchant system sends offer parametersthat specify an offer the merchant wishes to have distributed, and theaffiliate-network system adds the offer parameters to an offer datastore, as indicated by blocks 50 and 52. In some cases, the offerparameters include some or all of the fields of an offer recorddescribed above with reference to the offer data store 40. Sending theoffer parameters may include an employee of the merchant logging into amerchant account in the affiliate-network system with a username andpassword that indicate the employee is authorized to create an offer onbehalf of the merchant. The affiliate-network system may host a websiteinterface by which the employee of the merchant enters the offerparameters, or the employee the merchant may provide those parametersvia email or phone call or other form to an administrator of theaffiliate-network system who then enters the offer parameters. In somecases, the affiliate-network system provides an API by which a merchantcan programmatically submit a command to add an offer to the offer datastore along with data specifying the offer parameters in a formatspecified by the API. The offer parameters may be stored in one of theabove-mentioned offer records, and an arbitrary but unique offeridentifier may be created for the offer record.

In some cases, each offer record includes values indicating the state ofthe offer in an offer approval work-flow. For example, a value in therecord may indicate that the offer has been created, that the offer hasbeen sent to an employee of the merchant for approval, or that the offerhas been approved by an employee of the merchant with authority toapprove offers. In some cases, different roles defined by merchantrecords may specify which employees have authority to create offers orapprove offers. Interfaces to solicit changes in state within suchwork-flows may be hosted by the affiliate-network system, such as inweb-based interface by which an employee can approve an offer or rejectan entered offer. Such controls are helpful for merchants that manage arelatively large number of offers, any one of which could potentially berelatively expensive to the merchant were a mistake made in defining anoffer, for example, by making an offer that is more generous than themerchant intended. Not all embodiments, however, include these features,which is not to suggest that any other feature cannot also be omitted.

The process 44, in some embodiments, includes a publisher server (or apublisher employee or a publisher employee's user device) sendingpublisher content and parameters to the affiliate-network system todefine a new publisher account, and the affiliate-network system addingthe publisher to a publisher data store, as indicated by blocks 54 and56. In some cases, the publisher parameters and content may include someor all of the contents of the publisher records described above withreference to the publisher data store 38 of FIG. 1 . In some cases, thepublisher parameters are provided through a website hosted by theaffiliate-network system, the website presenting interfaces (e.g., textbox inputs, check boxes, radio buttons, file-uploaders for images) bywhich a publisher can populate a publisher record and upload publishercontent. Or publishers may send this information to an administrator ofthe affiliate-network system who then creates the publisher record inthe publisher data store. As noted above, in some embodiments, publisherrecords include data for customizing the presentation of offersaccording to the identity of the publisher such that when one publishersends a consumer a URI of a given offer, the offer appears differentlyon the consumer's user device relative to how that offer would appearhad a different publisher sent the same consumer the same offer. Asnoted, examples of such customization include button color, logos, linksto other publisher content, and the like. In some cases, the URIs foroffers sent to a given publisher include the name of the publisher, suchthat the appropriate publisher-specified visual attributes of offers canbe retrieved and applied when a consumer user device requests offercontent. In some cases, the portion of the URI identifying the publisheris provided by the publisher and is stored in a publisher record.Customizing the URI and visual aspects of offers content by publisher isexpected to make the affiliate-network system more desirable topublishers who may otherwise be concerned with distinguishing theirbrand from that of other publishers, while still providing a single,centralized system through which offer content is retrieved and throughwhich consumers interact with offers, such that both on-line andoff-line interactions with offers can be tracked. (Though not allembodiments necessarily provide these benefits.)

It should be noted that process 44, like the other processes describedherein, is not limited to the sequence illustrated. For example, in somecases, publishers may be added to the publisher data store beforemerchants are added to the merchant data store, and in some cases,multiple merchants, multiple offers, and multiple publishers may beadded at various points during the process 44, and multiple instances ofportions of process 44 may be performed concurrently (e.g., thousands ofoffers may be provided to millions of consumers at various times, andpublishers, merchants and offers may be added at various times). Thesteps 46-56 are merely exemplary steps illustrating the accumulation ofdata in the affiliate-network system for distributing offers.

The process 44, in some embodiments, includes the publisher serverrequesting offers for publication, and receiving this request through anAPI at the affiliate-network system, as illustrate d by blocks 58 and60. In some cases, the publisher server may periodically submit requestsfor offers (for instance, as a batch process run hourly or daily), orthe publisher server may request offers for publication in real-time(for example, in response to a request from a consumer user device tothe publisher server for offers). In some cases, the request may specifycriteria by which offers are to be selected. For example, the publishermay request offers specific to a geographic area, a category of goods orservices, a particular redemption channel (e.g., on-line or in-store), acategory of merchants, a particular merchant, or a particular timeperiod for expiration or publication (e.g., offers published since thelast time offers were requested by that publisher).

In response to the request, the affiliate-network system may retrieveresponsive offers (e.g., from the offer data store 40 of FIG. 1 ) andsend those offers to the publisher server, which may receive the offersfor publication, as indicated by blocks 62 and 64. In some cases, therequest for offers identifies the publisher, for example, with apublisher username and password provided in the API request, and theresponsive offers are filtered according to merchant selections eitherblacklisting or whitelisting publishers, as some merchants do not wishtheir offers to be associated with publishers inconsistent with themerchant's brand. In some cases, a plurality of responsive offerssatisfying both the publisher's criteria and merchants' constraints aresent. Offers may be sent, for example, in a serialized data format, suchas JSON or XML, to the publisher server according to a format for offersdefined by the API. In some cases, sending an offer includes sendingsome or all of an offer record stored in the offer data store 40.

Sending offers may include creating a publisher-specific URI for eachoffer (e.g., a URI that resolves to an Internet Protocol (IP) address ofthe affiliate-network system and includes the name of a publisher andthe unique offer identifier), such that when the publisher sends thatURI to a consumer user device, the consumer user device retrievespublisher-specific offer-content from the affiliate-network system, andthe name of the publisher in the URI gives the consumer confidence thatthey are viewing content “from” a publisher with which they arefamiliar.

The publisher server may store the received offers in a database of thepublisher, such that the publisher can later query the database foroffers responsive to requests from consumer user devices. Code executingon the publisher server may parse the API response and update apublisher database with records for the offers in accordance with apublisher's data model for offers. Or for real-time presentation via thepublisher, the publisher server may immediately send a consumer userdevice instructions to display the offers, along with information bywhich a visual presentation is constructed. The offers received by thepublisher, in some embodiments, are not accompanied by scripts, markupdata, and styling data for presenting a visually pleasing offerpresentation. Rather, publisher servers use the data provided via theAPI to construct such presentations on consumer user devices accordingto the particular website or application of the publisher. (Though someembodiments may also provide such scripts, markup data, and styling datawith the offers sent to the publisher.)

In some cases, the publisher processes the received offers prior toreceiving a request for offers from consumer user devices or prior toresponding to such requests. For instance, some publishers may indexoffers for faster offer retrieval according to various indices (e.g.,like keywords, redemption channel, geographic area, and the like). Somepublishers may associate offers with accumulated consumer feedback,e.g., upvotes or downvotes for offers or ratings of offers by consumers,and rank offers based on such feedback or index offers according to keywords in commentary. Offers may be ranked according to a variety ofgeographic, user-specific, or offer-specific criteria, including anexpected return to the publisher for a given ranking of the offer basedon historical redemption rates for a given offer and for offers andconsumers having various criteria similar to those at issue when rankingoccurs.

As illustrated, the process 44 continues in FIG. 3 . Some embodimentsinclude receiving, at the publisher server, a request for publishedoffers from a consumer user device, as indicated by blocks 66 and 68. Asnoted above, the consumer user device may be any of a variety ofdifferent types of computing devices, including mobile phones, tabletcomputers, laptop computers, desktop computers, set-top computers,in-dash automotive computers, gaming consoles, wearable computingdevices (such as smart watches or head-mounted displays), public kiosks,and the like. The request for published offers may be initiated by aconsumer interacting with a web browser or native application executingon the consumer user device, for example, by a user navigating to apublisher's webpage and interacting with that webpage to request offerssatisfying certain criteria. Or the request may come from a userinteracting with a native application for displaying offers, such as abarcode scanning application on a mobile device, or an application fordisplaying and discovering offers on a mobile device. In some cases, therequest for offers is initiated by a background process executing on themobile device, for example, a lock-screen-application on a cell phonethat displays offers to users automatically, an application on a mobiledevice for alerting consumers to offers based on the current geographiclocation of the user being proximate to a geolocation (e.g., within or athreshold distance) at which an offer is redeemable, or asocial-networking application through which the user receives alerts foroffers identified for the user by their friends.

In response to the request, the publisher server may identify responsiveoffers and send to the consumer user device a URI of the published offer(e.g., a publisher-and-offer-specific URI), as indicated by blocks 70and 72. In some cases, a plurality of offers are determined to beresponsive to the request, and a plurality of correspondingpublisher-and-offer-specific s are sent to the consumer user device, insome cases along with instructions to display information about theoffers to the consumer. In some embodiments, the information sent fromthe publisher to the consumer user device includes most or allinformation needed to construct an initial display of each offer, andthat initial display includes a link to the URI sent with the offer tothe publisher, such that when the user selects that link, additionalinformation about the offer is retrieved according to the URI.

In other cases, the publisher sends instructions to the consumer userdevice to retrieve information identified by the URIs without furtherinteraction by the user (or such instructions may be present within anative application executing on the consumer user device). For example,the publisher server may send a webpage with a plurality of otherwiseempty offer containers, each referencing a URI, and the consumer userdevice may automatically request content to populate each of thosecontainers (e.g., div-boxes, i-frames, or other DOM elements) withcontent identified by the respective URIs. As noted above, the URIs mayresolve to the affiliate-network system (e.g., on a different domainfrom the publisher) and, in some cases, include an identifier of thepublisher.

The consumer user device, in some embodiments, request offer contentidentified by each URI from the affiliate-network system, as indicatedby blocks 74 and 76. Requesting this content from the affiliate-networksystem rather than the publisher server provides a number of benefits,including more comprehensive tracking of consumer interactions withoffers than is generally available in traditional affiliate-networkingsystems, which often host the offer content, in its entirety, on thepublisher server. For example, embodiments of the affiliate-networksystem may centrally track interactions selecting the option to print anoffer, send an offer as a text message to a phone number, share theoffer in a social network, or send the offer to some other account, suchas an electronic wallet or card-linked offer account. In contrast,systems that rely on self-reporting by publishers can be difficult toadminister and properly audit. (Though not all embodiments necessarilyprovide these benefits, as some embodiments address other, independentproblems with existing systems.)

In some embodiments, the request for offer content itself constitutesone type of interaction tracked in one of the above-mentionedinteraction records in the tracking data store 42 of FIG. 1 . In somecases, publishers may be compensated for merely presenting offers,regardless of whether the consumer interacts further with the offer, forexample, by redeeming the offer. Thus, some embodiments include a stepof recording the request in a tracking data store, as indicated by block78. Recording the request may include populating some or all of theabove-mention fields in an interaction record described above based onthe request. To credit the publisher, the publisher's identity may beparsed from the request for offer content at the URI from the consumeruser device, or a publisher's script or native application on theconsumer user device may identify the publisher, e.g., with an APIrequest including the publisher's identity.

In some embodiments, receiving the request for offer content at theaffiliate-network system initiates an offer-presentation configurationprocess 80 that is a subroutine of the process 44 (which is not tosuggest that other portions of the process may not also constituteindependently useful subroutines). The offer-presentation configurationprocess 80, in some implementations, customizes the visual presentationof offers based on one or more of the following: the publisher thatidentified the offer to the consumer; or attributes of the consumer userdevice (including a printer) or account in which the offer will beviewed. These activities may be performed by the above-describedcontent-negotiation module 30. In some cases, the process 80 includesdetermining a version of offer content to send based on consumer userdevice attributes and determining and sending a publisher-specificpresentation of the offer content, as indicated by blocks 81 and 82.Examples of dynamically customized offer presentations are describedbelow with reference to FIGS. 7 and 8 . To simplify offer management andpresentation for publishers, the same URI may yield different visualpresentations of the offer appropriate to those devices or accounts.

The consumer user device may receive and display the customized offercontent, as indicated by block 84. The offer content may be displayed ina web browser or a special-purpose native application, depending uponthe use case, and some embodiments of the affiliate-network systemprovide offer content for both types of use cases. In some embodiments,the offer content specifies user interfaces for further interacting withthe offer content, such as buttons, gestures, text inputs, voice inputs,or the like, for the consumer to express an intent to take furtheraction with respect to a specific offer. The interfaces may beconfigured such that user selections of a given interface results in theuser selection being reported to the affiliate-network system along withdata identifying the publisher (e.g., with the request itself or with asession identifier associated with the publisher). Examples of suchfurther actions include printing the offer, texting the offer to a cellphone number, emailing the offer to an email address, sending the offerto a card-linked offer account, or sending the offer to an electronicwallet. Other examples include taking action to facilitate on-lineredemption of the offer, such as revealing an otherwise concealed orwithheld coupon code or loading such a coupon code to a clipboard memoryof the consumer user device, for instance, with a native mobileapplication or a flash object executing within a web browser, the flashobject having heightened security privileges relative to the defaultprivileges afforded scripts executing within a web browser for accessingclipboard memory.

The process 44 further includes receiving user interaction with theoffer content at the consumer user device, as indicated by block 86. Insome cases, the consumer user device executes an event handler thatlaunches various routines depending upon a user's input, and thoseroutines may initiate the requested actions, such as requesting theaffiliate-network system to send the offer to some other device oraccount. Depending on the type of the user's interaction, the process 44takes different paths, as indicated by decision block 88 identifyingalternate branches depending on whether on-line or off-line redemptionwas selected. In this embodiment, if on-line redemption is selected, theprocess 44 proceeds to the node labeled “B,” which is continued in FIG.4 , or if a form of off-line redemption is selected, the process 44proceeds to node “C,” which is continued in FIG. 5 .

FIG. 4 shows an example of what happens following a consumer selectionof on-line redemption. In this embodiment, the affiliate-network systemreceives, from the consumer user device, in response to the user'sselection, a request for on-line redemption information, as indicated byblock 98. The request may be a request for a coupon code, such as a codethat is withheld from the consumer user device until requested or isconcealed on the consumer user device until requested, or the requestmay be a request to navigate to the merchant's website. To preventpublishers from claiming credit for a consumer merely requesting contentfrom the publisher's domain, some embodiments require that a consumertake an additional affirmative step of selecting an offer before thepublisher is credited with the user's interaction, as some publishershave been known to send code to the consumer user device that indicatesin memory that the consumer selected the offer without the consumeractually having done so, thereby potentially causing the publisher to beovercompensated by the merchant. (Though it should be noted that not allembodiments must include this policy.)

Next, in this embodiment, the request is recorded (e.g., documented) inthe tracking data store and memory of the user device, as indicated byblock 100. Recording the request in the tracking data store may includecreating one of the above-mentioned interaction records described abovewith reference to FIG. 1 . Recording the request in memory of the userdevice may include sending and executing code on the consumer userdevice (e.g. JavaScript™ code) that loads a value into persistentclient-side storage remotely accessible to the domain of theaffiliate-network system (e.g., in a cookie or in LocalStorage). Or someembodiments only use one of client-side and server-side storage, whichis not to suggest that any other feature cannot also be omitted. Therecorded request may include an identifier of the publisher, such thatthe publisher can be compensated for the consumer's interaction or forlater interactions, like consumer redemption of the offer or consumerssharing the offer.

In some embodiments, the process 44 include both sending instructions torequest content from the merchant to the consumer user device andreceiving those instructions at the consumer user device, as indicatedby blocks 102 and 104. In some cases, the instructions are a redirectcommand sent to the consumer user device along with code that instructsthe consumer user device to store the request in a cookie orLocalStorage. The redirect command may cause the consumer user device tonavigate to a merchant's website and, in some cases, to a specificwebpage of the merchant associated with the offer (e.g., a product page)in an offer record in the above-mentioned offer data store 40.

The consumer user device, in response, may request content from themerchant, as indicated by block 106, and the merchant may receive thisrequest and send the requested content back to the consumer user device,as indicated by blocks 108, 110, and 112. This requested content may bethe merchant's webpage or content to be displayed in a merchant's nativeapplication executing on the consumer user device. In some cases, theconsumer and the merchant then complete the on-line transaction, asindicated by blocks 114 and 116. Completing the on-line transaction mayinclude the consumer selecting items or services for which the offerqualifies, providing payment information (e.g., identifying a creditcard account, a card-linked offer account, or an electronic walletaccount), and the consumer identifying the offer, for example, byentering a coupon code in a checkout page of the merchant. Examples ofcoupon codes include a relatively short, memorable string of text, likeless than 50 characters, or some other token, such as an image that theuser drags and drops into an interface on the checkout page. On-lineredemption of the offer is another example of a consumer interactiontracked in an interaction record in the tracking data store 42 of someembodiments.

In some cases, the on-line transaction is associated with the publisherat the affiliate-network system based on the record of the request foron-line redemption by the consumer, as indicated by block 118. In somecases, the checkout page of the merchant system includes instructionsfor the consumer user device to retrieve content from theaffiliate-network system, and that content includes scripts or otherinstructions that retrieve the identifier of the publisher from thepersistent client-side memory of the consumer user device, for instance,by reading a cookie or querying LocalStorage. Many browsers enforce asingle-origin policy for security reasons that only permit access tosuch memory by the domain that wrote to the memory. Accordingly, theaffiliate-network system may be able to retrieve the value identifying apublisher when the merchant cannot. In other embodiments or use cases,the publisher may be associated with the transaction based on apublisher-specific coupon code manually entered by a consumer in themerchant checkout page or an identifier of the publisher associated withthe offer in a consumer's account, such as a card-linked offer accountor an electronic wallet account used to pay for the transaction. In somecases, the association with the publisher is maintained in one of theabove-mention interaction records.

The process 44, in some embodiments, further includes steps tocompensate the publisher and bill the merchant for the publisher'scontribution to the transaction. This may include reporting theassociation of the on-line transaction with the publisher from theaffiliate-network system to both the merchant system and the publisherserver (or publisher employees), as indicated by blocks 120, 122, and124. Reporting the association may include calculating the amount owedby the merchant to the publisher or the affiliate-network systemoperator. In some cases, aggregate counts or rates are reported, andspecifics of each transaction are maintained in memory for auditingthose amounts owed. In some cases, the amount owed for a giventransaction is a function of the total amount spent in a transactionbetween the consumer and the publisher, and a total amount of theconsumers purchase is reported by the merchant to the affiliate-networksystem, for example, directly in association with a session identifierthat is also tied to the consumer's request for content at checkout, orvia a request for content itself. Steps 122 and 124, as illustrated,complete the branch of decision block 88 of FIG. 3 for on-lineredemption of an offer in this example.

FIGS. 5 and 6 show a branch of process 44 for off-line redemption of anoffer following from node “C” of decision block 88 in FIG. 3 . As noted,examples of off-line redemption include in-store redemption orredemption (or actions to facilitate redemptions) via other devices oraccounts. Upon a user interacting with offer content such that an intentfor off-line redemption is expressed, the consumer user device sends arequest for off-line redemption information to the affiliate-networksystem, as indicated by block 126 in FIG. 5 . The received request mayinclude an identifier of the publisher that provided the offer to theconsumer user device. The received request may then be stored in theabove-mentioned tracking data store, as indicated by block 128, forexample, in a new one of the interaction records described above. Thecorresponding interaction record may identify the publisher from whichthe consumer user device receive the offer and the type of redemptioninformation requested, for example, whether the consumer requestedredemption information to be sent to a phone number as a text message,to an email account as an email, to the consumer user device in a formatsuitable for printing, to a card-linked offer account, or to anelectronic wallet account. The resulting interaction record may be usedto determine compensation for publishers when the offer is redeemed on adifferent consumer user device or in-store.

With many existing affiliate-network systems, crediting publishers foroff-line redemptions is difficult, because many such systems rely onclient-side cookies for offer tracking that are not available when theconsumer redeems the offer using a different consumer user device, adifferent account, or a printed copy of the offer. In some embodimentsof the presently described processes and systems, the interaction recordcan be used as a basis for compensating publishers in these othercontexts. Further, directing the request for off-line redemptioninformation to the affiliate-network system consolidates such recordswith a single entity that can interface between merchants and publishersto determine such compensation.

Depending upon the type of off-line redemption information requested,the affiliate-network system takes various actions. Upon determiningthat the consumer selected a send-to-text option, the process 44 maysend the offer via text message to a phone number specified by therequest, as indicated by blocks 130 and 132. In some cases, the offerinterface presented on the consumer user device includes a text-boxinput for the consumer to identify a phone number upon indicating thatthey wish to send the offer to a mobile phone as a text message. Thisphone number may then be sent to the affiliate-network system tocomplete the request for off-line redemption information. In othercases, a user profile is maintained (e.g., in client-side or server-sidememory) that includes the phone number, and the number is retrieved frommemory for sending information to a mobile phone. Sending the offer inthis context may include sending a shortened description of the offerappropriate for mobile phone (for example, a one sentence summaryfollowed by an offer code) or may include sending a hyperlink to theoffer, such as a relatively short URL that links to a webpage for theoffer. To accommodate a relatively small namespace afforded by shortURLs, some embodiments may expire URLs after some duration, for exampleone year, and reuse the same URLs.

Later selections of the URLs on recipient mobile phones may be receivedat the affiliate-network system. Received selections may spawn newinteraction records in the tracking data store that are associated withthe corresponding offer and publisher. In some cases, consumers may sendthe offer to multiple phone numbers, for example, the phone numbers oftheir friends, and publishers may be compensated for multipleredemptions, thereby incentivizing publishers and merchants to interactwith the affiliate-network system. Some embodiments may restrict therate at which offers are sent to phone numbers to avoid abuse of thesystem by those sending un-desired text messages to others, for example,by maintaining a count of text messages sent from a given consumer userdevice over some trailing duration, and determining prior to sending anew text message whether the count exceeds a threshold (e.g., 50 textmessages per day). In some cases, a listing of phone numbers for whichusers have indicated they do not wish to receive offers is maintained,and before sending a text, the recipient number is verified to be absentfrom this list.

Some embodiments of the process 44 include determining whethersend-to-email was selected on the consumer user device and, in responseto such a selection, sending the offer to an email account specified bythe request, as indicated by blocks 134 and 136. In some cases, theinterface for interacting with offers presented on the consumer userdevice presents a text-box input upon a user selecting a button forsending the offer to an email account, and the user-entered emailaddress is sent as part of the request to the affiliate-network system.In response to the selection, some embodiments may construct anemail-specific and publisher-specific visual presentation of the offerwith the above-described content-negotiation module 30 and send thatpresentation, for example, in an HTML formatted email, to the specifiedemail address. In some cases, a listing of email addresses for whichusers have indicated they do not wish to receive offers is maintained,and before sending an email, the recipient email addresses verified tobe absent from this list. Further, to reduce the likelihood of undesiredemails being received, some embodiments determine whether the consumeruser device has sent more than a threshold amount of emails within sometrailing duration, using a process like that described above for textmessages.

Some embodiments of process 44 determine whether the consumer selected aprint-offer interface on the consumer user device and, in response, sendfrom the affiliate-network system a print-formatted version of theoffer, as indicated by blocks 138 and 140. Step 140 may include thecontent-negotiation module 30 described above constructing or selectinga publisher-specific and print-format specific visual presentation of anoffer. In some cases, the print-formatted version of the offer includesa barcode, a QR code, or other optically-machine-readable identifier ofthe offer for presentation at a point-of-sale terminal and scanning, forexample, with a barcode scanner or an optical scanner by a sales clerk.Some embodiments create an offer-specific, a publisher-specific, aconsumer-specific, or a session-specific scannable code, such that aprintout of the offer, when scanned at a point-of-sale terminal, yieldsdata that can be tied to an offer, a publisher, a consumer, or a sessionwith the affiliate-network system. For example, as described below, themerchant system may scan the code and store the code in memory inassociation with a merchant's record of the transaction. Merchanttransaction records may also indicate the date and time, what waspurchased, the purchase amount, the offer(s) that was (or were) redeemedduring the purchase, and in some cases, the identity of the consumer.Some or all of the merchant record may be sent to the affiliate-networksystem to determine compensation of the publisher. In embodiments withpublisher or session-specific codes, the code may be stored in theinteraction record stored in step 128 to tie the publisher with thein-store redemption. In other embodiments, a merchant supplied code isrepeated for each offer or a relatively large number of offers, suchthat the scannable code does not, by itself, identify the publisher orsession. Some merchant systems are incapable of validating single-useoffer codes and can only validate a relatively small number of codesthat are re-used. In some use cases, some embodiments determinecompensation for the publisher based on the interaction record, forexample, in a compensation per print model.

Some embodiments of process 44 determine whether the consumer selected asend-to-card-linked-offer account option on the consumer user deviceand, in response to such a selection, send the offer to an accountspecified by the request via an API of the card-linked-accountadministrator, as indicated by blocks 142 and 144. Card-linked offersare digital coupons or other offers loaded a credit card, debit card, orstore loyalty card account, such that when the respective card ispresented during a transaction, the offer is redeemed based on theassociation of the offer with the account. In some cases, consumer'scard-linked offer account information is requested upon selection ofthis interaction with a web form or other request for input sent to theconsumer user device, e.g., with a request to a native applicationexecuting on the consumer device that manages the consumer's card-linkedoffer accounts. In some cases, the information sent to the API includesa command to load the offer to the appropriate account and an identifiereither identifying the interaction record stored in step 128 or anidentifier of the publisher that should be compensated in the event theoffer is redeemed using the corresponding card. These identifiers may beused to determine compensation for the publisher when the offer isredeemed using the card, and either the merchant or the operator of thecard-link-offer account may report this information to theaffiliate-network system after (e.g., upon) redemption.

The process 44, in some cases, further includes determining whether theconsumer selected an option to send the offer to an electronic walletand, in response to such a selection, sending the offer to anelectronic-wallet API specified by the request, as indicated by blocks146 and 148. Examples of electronic wallet accounts include client-sideelectronic wallets (e.g., special purpose native applications executingon client-devices and implementing electronic wallet functionality) andserver-side electronic wallets (e.g., systems that host consumer accountinformation on a server that consumers access with a client-side“thin-wallet” application). Some client-side electronic walletapplications are configured for payment via NFC communication with apoint-of-sale terminal and to provide payment information for onlinetransactions (e.g., by populating checkout forms). During a transaction,the electronic wallet may electronically convey information to theseller to facilitate payment, along with information about offers beingredeemed in some cases. Like the card-linked offer example above, thesent information may include a command to load the offer to theelectronic wallet account along with identifiers of the publisher or theinteraction record in the tracking data store. One or more of theseidentifiers may be used to determine compensation for the publisher, andthe merchant or the entity operating or interacting with the electronicwallet account may report these identifiers to the affiliate-networksystem after redemption of the offer.

Thus, a variety of different off-line redemption channels are supportedin the present example. And it should be noted that a variety of otherredemption channels are consistent with the present techniques. Forexample, consumers may instruct the affiliate-network system to send theoffer to social networking accounts of other consumers, such that theoffer is presented within their friends' social networking accounts. Inanother example, consumers may share offers by transferring the offersto another consumer's user device with, for instance, a “bump” interfaceby which consumers physically bump their phones together, or with anon-screen gesture or interaction that instructs the mobile devices toexchange information via Bluetooth™, NFC, or other wireless connectionswith other, proximate mobile devices. Or consumers may instruct theaffiliate-network system to send the offer to themselves via one of thechannels described herein at some later date (e.g., as a reminder) orupon some condition obtaining (e.g., when the respective consumer'smobile user device enters some pre-defined geo-fence, such as onesurrounding one of the stores at which the offer is redeemable or theirhome or work, as indicated by a publisher's native mobile applicationthat is executing on the consumer's device and is configured to reportlocation to retrieve such reminders). Each such request may generate arecord in the tracking data store 42 described above, such thatpublishers can be compensated for various types of consumer interactionswith offers that merchants find desirable.

Further, some embodiments may generate additional interaction records(or values in such records) tracing the path of an offer through a chainof consumers who share the offer with one another. In some cases,merchants or publishers may wish to reward consumers for sharing offersvia off-line interactions. To this end, some embodiments store ininteraction records a recipient identifier (or list of suchidentifiers). When a later interaction record is created for interactionby the recipient, existing interaction records are queried for thosethat include the recipient's identifier, and if the offer is the same,the earlier interaction record is updated with an identifier for thelater interaction record. By tracing a chain of interaction recordsthrough such identifiers (which may be referred to as “links” or“pointers”), merchants and publishers may determine compensation forconsumers who share offers, e.g., calculating an amount of compensationbased on an percentage amount purchased by those with whom the offer wasshared. In some cases, merchants or publishers may configure offerrecords that specify compensation at one or more links in a chain oftransaction records that depends on multiple-downstream sharing events(e.g., at a decreasing rate for each subsequent sharing event), suchthat a single consumer can potentially be compensated for a relativelywide distribution of an offer if their friends share the offer widely topeople who, then, themselves share the offer widely. In some cases, suchrecords may also be queried by merchants or publishers to targetmarketing efforts to those consumers who historically have beenrelatively effective at distributing offers.

After determining the type of off-line transaction, embodiments of theprocess 44 execute the offer-presentation configuration process 80described above with reference to FIG. 3 , as indicated by block 80being repeated in FIG. 5 . In some cases, configuration includesformatting the offer for the various implicated APIs and associatingwith the offer publisher information to determine compensation, orconfiguring the offer may include forming an email-appropriate visualpresentation of the offer, or the above-mentioned text messagepresentations of offers. Templates specific to each configuration may beretrieved from memory, and the templates may be populated by retrievingresources and other information related to offers, publishers, andmerchants from a data store.

Upon configuring the offer presentation, the process 44 proceeds throughnode “D” to FIG. 6 , where the offer, as configured in the form of offercontent, is received at another consumer user device (e.g., a devicethrough which an email or text message is received) or account (e.g.,one of the above-mentioned card-linked offer accounts, electronic walletaccounts, social networking accounts, or the like), as indicated byblock 150. In some use cases, the “other” consumer user device is thesame user device used at a later time to access one of the recipientaccounts. Sometime after receipt, the other consumer user device oraccount may be used to present the offer at a point-of-sale terminal ata merchant's physical site (e.g., for in-store redemption), as indicatedby block 152. Or in some cases, the other consumer user device is usedto redeem the offer on-line, for example, using a URL linking to awebpage upon which the offer is presented, in which case, the process 44returns to node “B” described above in FIG. 4 and proceeds with thecurrent consumer user device.

In the case of in-store redemption, the offer information is received ata point-of-sale terminal that is part of the merchant system, asindicated by block 154. Receiving the offer may include a sales clerktyping in an offer code (e.g., either as shown on a printout ordisplayed on a screen of a mobile user device presented by the consumer)or other identifier. Or receiving the offer may include scanning anoptically-machine-readable code (e.g., scanning a bar code or QR codeeither on a printout or on a display screen of a mobile user devicepresented by the consumer). In some use cases, receiving the offer mayinclude a wireless exchange between the point-of-sale terminal and amobile user device (e.g., using near-field communication, infrared,Bluetooth™, or wireless area network connection to transfer data, suchas an offer identifier and in some cases payment information, between aconsumer's mobile device and the point-of-sale terminal). Thetransferred, scanned, or otherwise entered data may include anidentifier (or identifiers) associated with the offer (and in somecases, the affiliate-network and/or the publisher) and, in someimplementations, an identifier of the interaction record stored in step128.

The merchant system may complete the in-store transaction, as indicatedby block 156. Completing the transaction may include entering into thepoint-of-sale terminal identifiers of a plurality of different items orservices (e.g., scanned stock-keeping-units (SKUs) from barcodes),retrieving from memory of the merchant system prices for those items,calculating a total price for the transaction, and applying the offer tothe transaction, for example, calculating a discount for those items orservices to which the offer applies. Merchant transaction records mayalso include identifiers of the consumer or a financial account used bythe consumer, which some implementations may use to correlate thetransaction with, and reward, activities by the affiliate-network,publishers, and/or consumers. (The reader should note that the use of“and/or” does not imply that other uses of “or” are necessarily used inthe sense of an “exclusive or.”) In some cases, publishers arecompensated for the total amount of the purchase, even if the offeritself only applies to a subset of the goods or services that arepurchased. Thus some embodiments associate the total amount purchasedwith the offer redemption. The merchant system may store a transactionrecord in memory that includes a listing of the items purchased, theaffiliate-network, purchase amounts, a total purchased amount, and anidentifier of the offer, the publisher, the session with which the userreceive the offer, or a combination thereof.

The merchant system may send data describing the off-line, in-storetransaction to the affiliate-network system, which may receive thisdata, as indicated by blocks 158 and 160. In some cases, some or all ofthe merchant transaction record is sent. Sending the data may includeautomatically executing a process on the merchant system thatperiodically uploads the merchant records through an API of theaffiliate-network system, for example, nightly or hourly. Or someembodiments may upload the merchant records in real-time, for examplewithin minutes of the transaction. In some implementations, an employeeoperating a user device within the merchant system may manually takeaction to send the transaction record, for example, in a batch oftransaction records emailed daily to an administrator of theaffiliate-network system. The records received from the merchant may beparsed by the affiliate-network system and used to populatecorresponding interaction record in the tracking data store 42 describedabove.

Next, the affiliate-network system may associate the off-linetransactions with publishers (e.g., based on the data from the merchantand/or data collected by the affiliate-network in connection with thetransactions) and report the association to the publisher and themerchant, as indicated by blocks 162, 164, 166, and 168. Associating theoff-line transactions with the publisher may include calculating anaggregate amount owed by a given merchant to a given publisher based ontransactions associated with that publisher because of redemptions ofoffers identified to consumers by that publisher. Or, in another form ofassociating the transactions with the publisher, the affiliate-networkmay act as a financial intermediary, billing merchants, associating theoff-line transaction with the publisher, and compensating publishersbased on the transactions, such that the two groups need not interfacewith one another to transfer payment. For example, in some embodiments,the identifier discussed in paragraph 95 may only be unique to theaffiliate-network (rather than each publisher) so that the merchant mayassociate the transaction with the affiliate-network. In such cases, theaffiliate-network may associate the transaction with a publisher, orestimate the relative number of transactions that should be associatedwith a publisher based on data collected in connection with process 44.In some cases, records are maintained so that merchants and publisherscan audit the affiliate-network system.

In some implementations, multiple parties are compensated for atransaction. For instance, merchants or the affiliate-network may definecompensation models in merchant or offer records. The compensationmodels may specify an amount of compensation for each of severalpublishers who presented the offer to consumers (as indicated by theinteraction records), as some transactions are caused by repeatedexposure to offers. Some compensation models may divide a total rewardequally among each publisher, or some may allocate more credit to thefinal publisher or to those publishers whose presentation of an offerprecipitated a particularly desirable form of consumer interaction, suchas printing the offer. In some cases, compensation is calculated forboth consumers who shared an offer and publishers, e.g., calculatingpoints in a loyalty reward program for the consumer and a cash rewardfor the publisher.

Thus, some embodiments of process 44 compensate publishers for bothon-line and in-store redemptions, as well as redemptions that cross overonto other user devices or accounts (which generically may be referredto as “redemption channels”). As explained, some embodiments provide forrelatively wide distribution of offers by merchants across multiplechannels. Further, because some embodiments associate interactionrecords spanning multiple channels for redemption with a single offeridentifier, merchants and publishers can track activity relating tooffers across multiple channels and dynamically adjust their activitiesor content of the offer to enhance their performance, for example, upthe ranking of or increase the number of channels or discount amount foroffers that, in at least certain channels, are performing particularlywell, or terminating or reducing the discount amount for offers that arespreading more quickly or being redeemed in greater number than amerchant would desire when measured against activity across all channelsfor redemption. (Though, again, not all embodiments necessarily providethese benefits.)

The above-described processes are explained with reference to a singleoffer and with reference to alternate branches for on-line and off-lineredemption, but it should be understood that the steps of process 44 maybe repeated thousands of times per hour for thousands of offers, in somecases, concurrently among thousands of offers, thousands of publishers,and thousands of merchants for millions of consumers. Moreover, in someuse cases, affiliate-network systems become more useful as they acquirescale. Many merchants wish to have their offers distributed through manypublishers, and many publishers wish to have access to a wide array ofoffers. To support the desired scale, some embodiments may perform theprocess 44 with implementations of the affiliate-network system 12 (FIG.1 ) built with data centers that execute multiple instances of theabove-describe modules to support relatively large numbers of concurrentoperations.

As described above, the offer presentation configuration process 80 andcontent negotiation module 30 configure offer content based on variousparameters, such as those relating to the publisher and device oraccount through which the offer content will be accessed. To illustratethe resulting offer content, FIG. 7 shows an example of offer content170 configured for display in a relatively large display screen, DOMelement, or window. In some cases, the offer content 170 is web contentpresented within a web browser on a desktop computer, laptop computer, atablet computer, or the like. The illustrated offer content 170, in thiscase, includes various merchant resources associated with an offer and amerchant, including a merchant logo image 172 and a merchant banner 174(e.g., a div-box having a merchant selected color). The illustratedoffer content 170 also includes various resources and content specificto the offer, including a description of the offer 176, a summary of theterms of the offer 178, and a link to a more comprehensive descriptionof the terms of the offer 180.

The illustrated offer content 170 further includes user-selectableinterfaces 182 applicable to the offer. In this example, the interfaces182 include a print button 184, a text button 186, an email button 188,a card-linked offer button 190, and an electronic wallet button 192,which collectively constitute an exemplary set of off-line offerredemption interfaces. These interfaces may be used to facilitateredemption through another device (including a printer) or account.Further, the offer content 170 includes a button to show a coupon code194 for on-line redemption. In some cases, a coupon code is concealed orotherwise withheld from view to force the user to interact with theoffer content 170 to indicate interest in an offer before redemption.(Otherwise, a user may write down or memorize the offer code andmanually enter that code in a merchant's checkout page, therebypreventing the publisher from being credited with the transaction,though some embodiments also display the code initially.) The offercontent 170 may include scripts, such as JavaScript™, that execute upona user selecting one of the buttons (e.g., in response to an on-clickevent or an on-touch event), and those scripts may initiate theabove-described steps of process 44 that implement the requestedfunctionality.

The offer content 170 may also include content specified by thepublisher, including a banner 196 of a color selected by the publisherto match the publisher's branding and an image of the publisher's logo198, along with text and links associated with the publisher's website(or corresponding API calls to a publisher's native application).Further, the URI 202 with which the offer content 170 was retrieved fromthe affiliate-network system 12 includes a domain of theaffiliate-network system 204, the name of the publisher 206, the name ofthe merchant 208, and an identifier of the offer 210. In some cases,this URI is provided to consumer user devices, as described above, sothat consumer interactions can be tracked across multiple channels bycentralizing requests with the affiliate-network system 12. Further,including the publisher's named in the URI and including publishercontent in the offer content 170 allows multiple publishers to maintaindistinct brands, while using a centralized service to host offercontent.

FIG. 8 shows another example of offer content 212 configured for displayon a relatively small display screen, DOM element, or window. In somecases, the offer content 212 is obtained with reference to the same URI202 as the offer content 170 of FIG. 7 . This example of offer contentincludes a merchant image 214 associated with the offer or the merchant,which may be a lower-resolution version of the image 172 (FIG. 7 ) toaccommodate the smaller display area. The illustrated offer content 212also includes a banner 216, which may be of a color selected by themerchant or the publisher, depending upon the implementation. The offerdescription 176 and summary of terms 178 is also used in the offercontent 212, though some versions may store and display a shorterversion of the description or terms for smaller displays. In thisexample, the offer content 212 includes a different set of offerinterfaces 218, as specified by the above-mentioned templates and theoffer record for the offer being displayed (e.g., some offers are onlyredeemable on-line). In this case, the interfaces include a card-linkedoffer button 190, and the electronic wallet button 192 to facilitatein-store usage of the offer by sending the offer to an account withwhich the consumer can pay for a transaction and apply the offer.Interfaces also include buttons 192 and 188 showing the offer code oremailing the offer, respectively. Further, this example includes anoptically scannable image 220, in this case, a barcode image, thoughother types of such images may be used, including temporally changingpatterns (e.g., codes transmitted by flashing a pattern on a displayscreen), or QR codes. As noted above, some embodiments may dynamicallygenerate single-use offer codes, and the barcode image 220 may bedynamically generated, for example at the time the offer content 212 isrequested. The offer content 212 also includes the publisher links andinformation 200.

The two versions of offer content 170 and 212 may both be retrievedusing the same URI 202 and may be specified by different templatesselected based on the type of consumer user device, account, or displaywindow in which the offer will be displayed. Those templates may bepopulated, in part, with resources and other content provided by thepublisher, such that the presentation is customized to be in accordancewith the publisher's brand, and the offer content 170 and 212 generallymay be selected in view of the size of display and likelihood that thedisplay will be carried into a store to be presented at a point-of-saleterminal. Other forms of offer content may accommodate APIs specifiedfor adding the offer to a card-linked offer account or an electronicwallet. Further, some versions may include templates for HTML, formattedemails and text formatted emails.

As noted above, centralizing tracking of interactions with offers acrossmultiple channels allows merchants and publishers to track theperformance of a given offer through multiple forms of redemption andother interactions. FIGS. 9 and 10 show examples of analytic s generatedbased on the above-described interaction records. FIG. 9 shows ascreenshot of merchant metrics 222 by which a merchant can view (e.g.,via a web browser) and interact with various statistics associated withredemptions of (or other interactions with) offers across multiplechannels. Similarly, FIGS. 10A and B show portions of a screenshot ofpublisher metrics 224 by which publishers can perform similar analyses.The screenshots 222 and 224 include various interfaces by whichpublishers and merchants can query data specific to offers, date ranges,merchants, publishers, consumer user device operating system, channel,geographic distribution, and the like. Using responsive data, merchantsand publishers may adjust their strategies related to offers to improvetheir performance.

In some embodiments, the interaction records may be used to dynamicallyadjust the terms of offers with a process 226 based on consumerinteractions both in-store and on-line. The process 226 may be performedby the above-described affiliate-network system 12 of FIG. 1 , thoughembodiments are not limited to that implementation. In some cases, theprocess 226 is performed by a data processing apparatus executing codespecifying steps of process 226 in a non-transitory, machine-readable,tangible medium, examples of which are described below with reference toa computer system of FIG. 12 . Dynamically adjusting the terms of offersis expected to become more desirable as merchants issue increasingnumber of offers redeemable across multiple channels and being ofincreasing complexity, for example, varying in geographic applicability,having a shorter term, using AB testing, and applying to narrower setsof conditions.

Adjusting the terms of offers can refer to a number of differentactivities that change the universe of offers presented to consumers. Insome cases, dynamically adjusting the terms of an offer includescanceling the offer, for example, by ceasing to send the offer topublishers, or by sending a message to publishers to stop publishing anoffer that has already been sent to them. In some cases, dynamicallyadjusting the terms of an offer includes automatically generating newoffers based on an existing offer (e.g., changing one or two terms orattributes—including images and other resources—of an existing offer ina merchant-specified fashion), such that subsequent publisher requestsretrieves the new, dynamically generated offer, and the previouslypresented offer is no longer published. Thus, consumers who, forexample, printed an earlier iteration of an offer may have a print-outwith a barcode that ties to the previous terms of the offer, prior todynamic adjustment of the new terms, while a consumer who prints a newversion of the offer after dynamic adjustment will receive a differentbarcode, tied to the dynamically adjust the terms. These terms may besent to a merchant's system (e.g., via a merchant API) to update amerchant database for applying the offer in-store with the new terms.

The process 226, in this embodiment, begins with obtaining adynamic-offer algorithm specified by a merchant, as indicated by block228. In some cases, merchants specify this algorithm by, for instance,entering threshold rates or amounts of particular types of consumerinteractions with a given offer (or collection of offers) and indicatingactions to be taken upon those thresholds being exceeded, for example,requesting an alert be sent to the merchant, requesting that the offerno longer be published, or requesting that a new offer with less or moregenerous terms be generated and published instead of the current offer.For instance, the algorithm may indicate that a given offer is to bereplaced with a new offer with a 5% smaller discount or shorterexpiration date in response to the amount of consumer interactions viasocial-network sharing exceeding a threshold of 50,000 suchinteractions. Or embodiments may specify that an offer related to wintercoats is to be issued and valid in geographic areas in which the weatherforecast calls for temperatures below 45-degrees Fahrenheit within thenext 5 days.

The process 226, in some cases, further includes obtaining feed-forwardparameters of the dynamic-offer, as indicated by block 230. Somemerchants may wish to adjust the terms of offers based on data externalto the affiliate-network systems. For example, a merchant may specifythat an offer be initiated or terms of an offer be adjusted in responseto a change in the weather (for instance, to offer a discount on raingear when rain is expected), a particular result in a sporting event(for instance, to discount jerseys of a winning or losing footballteam), or based on an amount or rate of occurrence of some term in adata-feed indicative of on-line activity, like the occurrence of a termin search queries or social network data feeds, indicating that aparticular brand or item has become popular (for instance, specifying adiscount on a particular brand of shoes in response to that brand nameoccurring above a threshold rate within search queries on-line). Not allembodiments, however, obtain or use such feed-forward parameters, whichis not to suggest that any other feature cannot also be omitted.

Some embodiments of process 226 further include obtaining feed-backparameters of the dynamic-offer, such parameters including dataindicative of both on-line usage and off-line usage of the offer, asindicated by block 232. The feed-back parameters may include theabove-mentioned interaction records, for example, a rate, an amount, ortypes of such interaction records. In one case, a merchant may specifythat the terms of an offer are to be adjusted in response to more than athreshold amount of interactions indicating a consumer has sent theoffer to more than one recipient to limit the spread of an offer that isparticularly generous. In another example, merchants may request analert when more than a threshold rate of interaction records aregenerated for a given offer, for example, more than five standarddeviations of the typical rate of accumulation of offer interactionsthat occurs for that merchant. Such anomalous rates may be indicative ofan error in the offer, for example, offering a price discount that islarger than what the merchant intended to offer, in which case, themerchant may wish to dynamically or manually adjust the terms of thatoffer.

The process 226, in some embodiments, further includes creating a newversion of the offer with terms adjusted based on the feed-forward andthe feed-back parameters, as indicated by block 234. As noted above,this step may include canceling an offer, sending a message topublishers requesting that they cease publishing an offer, and creatinga new offer with different terms, for example, with a 5% smallerdiscount, a 5% larger discount, a five dollars smaller discount, a fivedollar larger discount, a shorter expiration date, or a longerexpiration date. Further, as noted above, some merchants may specifythat an alert is to be sent to the merchant, so the merchant canmanually intervene.

The process 226 may further include storing the new version of the offerin an offer data store, as indicated by block 236. Storing the newversion of the offer may include creating a new offer record in theabove-described data store 40 of FIG. 1 , for example by cloning theexisting record upon which the feed-back is based and adjusting theterms in the new record based on the instructions provided by themerchant in the dynamic-offer algorithm. Alternatively, storing the newversion of the offer may include changing a record of an existing offerto indicate that the offer is to no longer be published.

Thus, some embodiments of the process 226 allow merchants to automatethe management of offers and respond relatively quickly to changes ininteractions with offers and to changes in likely demand for offers,across multiple channels of offer redemption. Further, some merchantsmay use the automation process to AB test offers, issuing offers withlow-thresholds before cancellation, and measuring the response ofconsumers to differences between offers, refining offer terms and offercontent to increase efficacy. The process 226 can be used with theabove-described affiliate-network system 12 and process 44, which aresuited to producing feed-back data by which offers may be relativelyreliably automatically changed, but the process 226 is not limited tothose implementations and is independently useful in other environments.

FIG. 12 is a diagram that illustrates an exemplary computing system 1000in accordance with embodiments of the present technique. Variousportions of systems and methods described herein, may include or beexecuted on one or more computer systems similar to computing system1000. Further, processes and modules described herein may be executed byone or more processing systems similar to that of computing system 1000.

Computing system 1000 may include one or more processors (e.g.,processors 1010 a-1010 n) coupled to system memory 1020, an input/outputI/O device interface 1030, and a network interface 1040 via aninput/output (I/O) interface 1050. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1000. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1020). Computing system 1000 may be a uni-processor systemincluding one processor (e.g., processor 1010 a), or a multi-processorsystem including any number of suitable processors (e.g., 1010 a-1010n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1000may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1030 may provide an interface for connection of oneor more I/O devices 1060 to computer system 1000. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1060 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1060 may be connected to computer system 1000through a wired or wireless connection. I/O devices 1060 may beconnected to computer system 1000 from a remote location. I/O devices1060 located on remote computer system, for example, may be connected tocomputer system 1000 via a network and network interface 1040.

Network interface 1040 may include a network adapter that provides forconnection of computer system 1000 to a network. Network interface may1040 may facilitate data exchange between computer system 1000 and otherdevices connected to the network. Network interface 1040 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1020 may be configured to store program instructions 1100or data 1110. Program instructions 1100 may be executable by a processor(e.g., one or more of processors 1010 a-1010 n) to implement one or moreembodiments of the present techniques. Instructions 1100 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1020 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or thelike. System memory 1020 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1010 a-1010 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1020) may include asingle memory device and/or a plurality of memory devices (e.g.,distributed memory devices).

I/O interface 1050 may be configured to coordinate I/O traffic betweenprocessors 1010 a-1010 n, system memory 1020, network interface 1040,I/O devices 1060, and/or other peripheral devices. I/O interface 1050may perform protocol, timing, or other data transformations to convertdata signals from one component (e.g., system memory 1020) into a formatsuitable for use by another component (e.g., processors 1010 a-1010 n).I/O interface 1050 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1000 or multiple computer systems1000 configured to host different portions or instances of embodiments.Multiple computer systems 1000 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1000 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1000 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1000 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1000 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1000 may be transmitted to computer system1000 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present invention may be practiced with othercomputer system configurations.

It should be understood that the description and the drawings are notintended to limit the invention to the particular form disclosed, but tothe contrary, the intention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of the presentinvention as defined by the appended claims. Further modifications andalternative embodiments of various aspects of the invention will beapparent to those skilled in the art in view of this description.Accordingly, this description and the drawings are to be construed asillustrative only and are for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as examples of embodiments. Elements and materials maybe substituted for those illustrated and described herein, parts andprocesses may be reversed or omitted, and certain features of theinvention may be utilized independently, all as would be apparent to oneskilled in the art after having the benefit of this description of theinvention. Changes may be made in the elements described herein withoutdeparting from the spirit and scope of the invention as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if Y,” “whenY,” and the like, encompass causal relationships in which the antecedentis a necessary causal condition, the antecedent is a sufficient causalcondition, or the antecedent is a contributory causal condition of theconsequent, e.g., “state X occurs upon condition Y obtaining” is genericto “X occurs solely upon Y” and “X occurs upon Y and Z.” Suchconditional relationships are not limited to consequences that instantlyfollow the antecedent obtaining, as some consequences may be delayed,and in conditional statements, antecedents are connected to theirconsequents, e.g., the antecedent is relevant to the likelihood of theconsequent occurring. Further, unless otherwise indicated, statementsthat one value or action is “based on” another condition or valueencompass both instances in which the condition or value is the solefactor and instances in which the condition or value is one factor amonga plurality of factors. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.

The present techniques will be better understood when considered in viewof the following enumerated embodiments:

-   1. A method of providing offers to consumers, the method comprising:    obtaining offers redeemable across multiple channels; providing the    offers to publishers; and tracking, with a computer system, consumer    interactions across multiple channels with offers provided to the    consumers by the publishers.-   2. The method of embodiment 1, comprising: obtaining a coupon issued    by a merchant, the coupon being redeemable both on-line, at the    merchant's website, and in-store, at a physical location of the    merchant; sending the coupon to publishers for presentation to    consumers by the publishers on user devices of the consumers;    receiving indications from the user devices of the consumers that    the consumers interacted with the coupon, the indications indicating    a consumer selection of an in-store redemption option or an on-line    redemption option;

after an indication that a given consumer selected an in-storeredemption option, effectuating operations comprising: sending the givenconsumer in-store redemption data documenting that the given consumer isin possession of the coupon for presentation to the merchant at aphysical location of the merchant, the data identifying a firstpublisher that presented the coupon to the given consumer to creditfirst publisher; receiving transaction data from the merchant indicatingthat the given consumer redeemed the coupon; determining compensationfor the first publisher based on the transaction data; and

after an indication that another given consumer selected an on-lineredemption option, effectuating operations comprising: storing on-lineredemption data in memory documenting that the other given consumerselected the coupon and identifying a second publisher that presentedthe coupon to the other given consumer to credit the publisher; andinstructing the user device of the other given consumer to requestcontent from the merchant's website; obtaining the on-line redemptiondata stored in memory upon the other given consumer redeeming thecoupon; and determining compensation for the second publisher based onthe obtained on-line redemption data.

-   3. The method of embodiment 2, comprising: after sending the coupon    to publishers, obtaining a request from a user device of a consumer    who selected the coupon upon presentation by a given publisher, the    request identifying the given publisher, the coupon, and indicating    display capabilities of the user device; preparing a presentation of    the coupon based on the display capabilities, the coupon, and the    given publisher by performing operations comprising:

retrieving an coupon presentation template corresponding to the displaycapabilities from memory; retrieving from memory publisher-specificcontent to be added to the retrieved template; retrieving from memoryredemption options of the coupon to be added to the retrieved template,the redemption options indicating that the coupon is redeemable in-storeand on-line; and sending to the user device instructions to display thecoupon according to the retrieved template, publisher-specific content,and redemption options in a user interface by which the consumer selectson-line redemption or in-store redemption.

-   4. The method of embodiment 3, wherein: sending the coupon to the    given publisher comprises sending a publisher-and-coupon specific    uniform resource identifier (URI) of the coupon and the publisher;    the request from a user device of a consumer who selected the coupon    comprises user agent information indicative of display capabilities;    retrieving publisher-specific content comprises retrieving images of    the given publisher's brand and colors selected by the given    publisher; and the in-store redemption option includes an option to    print the coupon, a option to send a network address of a    presentation of the coupon via text message, and an option to email    a network address of a presentation of the coupon.-   5. The method of any of embodiments 2-3, wherein receiving    indications from the user devices of the consumers that the    consumers interacted with the coupon comprises: after sending a    first presentation of the coupon to a first user device of a    consumer, receiving a request from the consumer to send information    about the coupon to another user device or account via short-message    service (SMS) text message, or email, or a card-linked offer    application program interface.-   6. The method of any of embodiments 2-5, wherein: sending the coupon    is associated a geographic area in which the coupon is redeemable,    the geographic area being specified by the merchant; and sending the    coupon to publishers comprises: receiving a request from a publisher    for coupons redeemable within a queried geographic area; determining    that geographic area associated with the coupon is at least    partially within the queried geographic area; and in response to the    determination, sending the coupon to the publisher from which the    request was received.-   7. The method of any of embodiments 2-6, comprising determining    compensation for the same publisher based on both in-store usage of    the coupon and on-line usage of the coupon.-   8. The method of embodiment 1, comprising: obtaining a plurality of    offers from merchants, each offer being redeemable on-line and    in-store; sending information about the offers to a plurality of    publishers, each publisher informing consumers of the offers    on-line; tracking, with one or more processors, usage of the offers    by consumers; allocating credit for usage of the offers by consumers    to the publishers based on the tracking; and sending information    about the allocation of credit to merchants and publishers.-   9. The method of embodiment 8, wherein sending information about the    offers to a plurality of publishers comprises: for each publisher    and for each offer, sending the respective publisher information    specifying a respective uniform resource identifier (URI) of the    respective offer, such that each publisher has a different,    publisher-specific URI for each offer to be included in content    provided by the respective publisher to consumers.-   10. The method of embodiment 9, receiving a request for content    identified by a given publisher-specific URI for a given offer from    a user device of a consumer that received the given URI from the    given publisher; and sending the content to the user device of the    consumer that requested the content.-   11. The method of embodiment 10, comprising sending the content to a    user device of a consumer that requested the content with steps    comprising: determining a version of the content based on the    identity of the publisher specified by the publisher-specific URI.-   12. The method of embodiment 10, comprising: in response to the    request for content identified by the given publisher-specific URI,    tracking that the given publisher presented the corresponding offer    to a consumer.-   13. The method of any of embodiments 8-12, comprising sending    content to a user device of a consumer that requested content    describing the offer with steps comprising: obtaining information    about the type of user device of the consumer the requested the    content; and determining a version of the content based on the type    of user device.-   14. The method of any of embodiments 8-13, comprising sending    content to a user device of a consumer that requested content    describing the offer, wherein the content includes a user-interface    by which a consumer interacts with an offer, the user-interface    including interaction options to navigate to a website of the    corresponding merchant and to send the offer to another device or    account of the consumer for in-store usage of the offer.-   15. The method of embodiment 14, wherein: tracking usage of the    offers by consumers comprises tracking user interactions requesting    that the offer be sent to another device or account; and allocating    credit for usage of the offers comprises attributing credit for the    tracked user interactions to a publisher that provided a URI by    which the content was requested by the user device of the consumer.-   16. The method of any of embodiments 14-15, comprising: receiving a    request to send the offer to another device, the other device being    a mobile phone, and the request specifying a cell phone number of    the other device; and sending a link to, or other information about,    the offer via text message with the cell phone number.-   17. The method of any of embodiments 14-16, comprising: receiving a    request to send the offer to an email address; and sending a link    to, or other information about, the offer via email to the email    address.-   18. The method of any of embodiments 14-17, comprising receiving a    request to send the offer to a card-linked offer account; and    sending a request to load the offer to the card-lined offer account.-   19. The method of any of embodiments 14-18, comprising: receiving a    request to send the offer to an electronic wallet application on a    mobile phone; and sending a request to load the offer to the    electronic wallet application.-   20. The method of any of embodiments 14-19, comprising: receiving    data indicative of consumer demand for goods or services; and    automatically adjusting terms of one of the offers based on the data    indicative of consumer demand.-   21. The method of embodiment 20, wherein the data indicative of    consumer demand includes one or more of the following: a weather    forecast, and aggregated feedback of both on-line usage and in-store    usage of the one of the offers.-   22. The method of any of embodiments 8-21, wherein sending    information about the offers to a plurality of publishers comprises:    receiving a request from a given publisher for offers redeemable in    a geographic area specified by the request; determining which offers    are designated as being redeemable in the geographic area; sending    responsive offers to the given publisher.-   23. A method of dynamically adjusting offers, the method comprising:    obtaining one or more dynamic-offer rules, the one or more    dynamic-offer rules specifying aspects of an offer to be published    automatically after conditions specified by the dynamic-offer rules    occur; after obtaining one or more dynamic-offer rules, obtaining    data indicative of the conditions; automatically, with one or more    computers, forming an offer with aspects specified by the one or    more dynamic-offer rules; and sending the formed offer over the    Internet to a remote computer.-   24. The method of embodiment 23, wherein the conditions include both    an amount of on-line redemptions and an amount of off-line    redemptions of a coupon with a merchant.-   25. The method of embodiment 24, wherein the rules specify an amount    of a discount on the purchase of a good or service to be offered in    response to an aggregate value including in-store and on-line    redemptions of an offer exceeding a threshold.-   26. The method of any of embodiments 23-25, wherein: the conditions    include data indicative of weather in a geographic area; and the one    or more dynamic-offer rules specify an offer to be published in    response to data indicative of weather.-   27. The method of embodiment 26, wherein an aspect of the offer    includes a geographic restriction on in-store redemption, the    geographic restriction corresponding to the geographic area.-   28. The method of any of embodiments 23-27, wherein: the conditions    include data indicative of a result in a sporting event; and the one    or more dynamic-offer rules specify an offer to be published in    response to the data indicative of a the result in the sporting    event.-   29. The method of any of embodiments 23-28, wherein sending the    formed offer over the Internet to a remote computer comprises    sending the offer to a plurality of publishers for presentation to    consumers.-   30. The method of any of embodiments 23-29, wherein the conditions    include an amount of sharing of the offer among consumers.-   31. The method of any of embodiments 23-30 combined with the method    of any of embodiments 1-22.-   32. A tangible, non-transitory, machine-readable medium storing    instructions that when executed by a data processing apparatus cause    the data processing apparatus to effectuate operations comprising    any of the methods of embodiments 1-31.-   33. An affiliate-network system configured to act as an intermediary    between merchants issuing coupons or other offers and publishers    promoting the offers to consumers, the affiliate-network system    being configured to distribute and track usage of both on-line    offers and in-store offers, the system comprising: one or more    processors; memory storing instructions that when executed by one or    more of the one or more processors effectuate operations comprising    any of the methods of embodiments 1-31.

What is claimed is:
 1. An affiliate-network system configured to act asan intermediary between merchants issuing offers and publisherspromoting the offers to consumers, the affiliate-network system beingconfigured to distribute and track usage of both on-line redemptions andin-store redemptions, the system comprising: one or more processors;memory storing instructions that when executed by one or more of the oneor more processors effectuate operations comprising: obtaining an offerissued by a merchant, the offer being redeemable both on-line, at themerchant's website, and in-store, at a physical location of themerchant; sending the offer to publishers for presentation to consumersby the publishers on user devices of the consumers; for an in-storeredemption receiving transaction data from a merchant system of themerchant indicating that a given consumer redeemed the offer and that afirst publisher presented the offer to the given consumer, anddetermining compensation for the first publisher based on thetransaction data; and for an on-line redemption receiving a request froma user device of another given consumer for offer content wherein therequest identifies a second publisher, and in response sending offercontent that includes publisher-specific presentation of the offer, tothe user device, instructing the user device to load a value thatidentifies the second publisher into persistent client-side storage of abrowser of the user device, the value as loaded into persistentclient-side storage is i) remotely accessible to a given domain fromwhich the instruction to load the value into persistent client-storageis sent, and ii) remotely inaccessible to domains other than the givendomain under a single-origin policy of the browser of the user device,receiving a request from the user device for online redemptioninformation of the offer and in response instructing the user device torequest content from the merchant's website, sending instructions fromthe given domain that cause the user device to access the value loadedinto persistent client-side storage, and determining compensation forthe second publisher based on the accessed value.
 2. Theaffiliate-network system of claim 1, wherein the request from the userdevice for offer content identifies display capabilities of the userdevice, and the memory stores instructions that when executed by one ormore of the one or more processors: prepare the publisher-specificpresentation of the offer content based on the display capabilities, theoffer, and the given publisher by retrieving an offer presentationtemplate corresponding to the display capabilities from memory,retrieving from memory publisher-specific content to be added to theretrieved template, and retrieving from memory redemption options of theoffer to be added to the retrieved template, the redemption optionsindicating that the offer is redeemable in-store and on-line; andwherein sending publisher-specific presentation of the offer content tothe user device comprises sending to the user device instructions todisplay the offer according to the retrieved template,publisher-specific content, and redemption options in a user interfaceby which the consumer selects on-line redemption or in-store redemption.3. The affiliate-network system of claim 2, wherein: sending the offerto publishers comprises sending a publisher-and-offer specific uniformresource identifier (URI); retrieving publisher-specific contentcomprises retrieving images of a given publisher's brand and colorsselected by the given publisher; and the redemption options include anin-store redemption option that comprises an option to print the offer,an option to send a network address of a presentation of the offer viatext message, and an option to email a network address of a presentationof the offer.
 4. The affiliate-network system of claim 1, whereinreceiving a request from a user device for offer content comprises aftersending a first presentation of the offer to a first user device of aconsumer, receiving a request from the consumer to send informationabout the offer to another user device or account viashort-message-service (SMS) text message, or email, or a card-linkedoffer application program interface.
 5. The affiliate-network system ofclaim 1, wherein: sending the offer to publishers is associated with ageographic area in which the offer is redeemable, the geographic areabeing specified by the merchant; receiving a request from a publisherfor coupons redeemable within a queried geographic area; and determiningthat the geographic area associated with the offer is at least partiallywithin the queried geographic area and in response sending the offer tothe publisher from which the request was received.
 6. The system ofclaim 1, wherein the offer content sent to the user device configuresthe user device to return to the affiliate-network system any userinteractions with the offer.
 7. The system of claim 1, wherein thememory stores instructions that when executed by one or more of the oneor more processors host the offer content that publishers embed.
 8. Thesystem of claim 1, wherein the memory stores instructions that whenexecuted by one or more of the one or more processors providemulti-channel access to an offer through a single uniform resourceidentifier.
 9. The system of claim 1, wherein the memory storesinstructions that when executed by one or more of the one or moreprocessors provide analytics to both merchants and publishers thataggregate both on-line and off-line consumer interactions.
 10. Thesystem of claim 1, wherein the memory stores instructions that whenexecuted by one or more of the one or more processors dynamically adjustthe terms of offers based on feedback from multiple channels of offerredemption, including on-line and in-store redemptions.
 11. The systemof claim 1 wherein sending the offer to publishers comprises sending apublisher-and-offer specific uniform resource identifier (URI) thatconfigures a browser to retrieve content from the affiliate-networksystem.
 12. A method performed by a server system that acts as anintermediary between merchants issuing offers and publishers promotingthe offers to consumers, to distribute and track usage of both on-lineredemptions and in-store redemptions, the method comprising: obtainingan offer issued by a merchant, the offer being redeemable both on-line,at the merchant's website, and in-store, at a physical location of themerchant; sending the offer to publishers for presentation to consumersby the publishers on user devices of the consumers; for an in-storeredemption receiving transaction data from a merchant system of themerchant indicating that a given consumer redeemed the offer and that afirst publisher presented the offer to the given consumer, anddetermining compensation for the first publisher based on thetransaction data; and for an on-line redemption receiving a request froma user device of another given consumer for offer content wherein therequest identifies a second publisher, and in response sending offercontent that includes publisher-specific presentation of the offer, tothe user device, instructing the user device to load a value thatidentifies the second publisher into persistent client-side storage of abrowser of the user device, the value as loaded into persistentclient-side storage is i) remotely accessible to a given domain fromwhich the instruction to load the value into persistent client-storageis sent, and remotely inaccessible to domains other than the givendomain under a single-origin policy of the browser of the user device,receiving a request from the user device for online redemptioninformation of the offer and in response instructing the user device torequest content from the merchant's website, sending instructions fromthe given domain that cause the user device to access the value loadedinto persistent client-side storage, and determining compensation forthe second publisher based on the accessed value.
 13. The method ofclaim 12, wherein the request from the user device for offer contentidentifies display capabilities of the user device, the method furthercomprising: prepare the publisher-specific presentation of the offercontent based on the display capabilities, the offer, and the givenpublisher by retrieving an offer presentation template corresponding tothe display capabilities from memory, retrieving from memorypublisher-specific content to be added to the retrieved template, andretrieving from memory redemption options of the offer to be added tothe retrieved template, the redemption options indicating that the offeris redeemable in-store and on-line; and wherein sendingpublisher-specific presentation of the offer content to the user devicecomprises sending to the user device instructions to display the offeraccording to the retrieved template, publisher-specific content, andredemption options in a user interface by which the consumer selectson-line redemption or in-store redemption.
 14. The method of claim 13,wherein: sending the offer to publishers comprises sending apublisher-and-offer specific uniform resource identifier (URI);retrieving publisher-specific content comprises retrieving images of agiven publisher's brand and colors selected by the given publisher; andthe redemption options include an in-store redemption option thatcomprises an option to print the offer, an option to send a networkaddress of a presentation of the offer via text message, and an optionto email a network address of a presentation of the offer.
 15. Themethod of claim 12, wherein receiving a request from a user device foroffer content comprises after sending a first presentation of the offerto a first user device of a consumer, receiving a request from theconsumer to send information about the offer to another user device oraccount via short-message-service (SMS) text message, or email, or acard-linked offer application program interface.
 16. The method of claim12, wherein: sending the offer to publishers is associated with ageographic area in which the offer is redeemable, the geographic areabeing specified by the merchant; receiving a request from a publisherfor coupons redeemable within a queried geographic area; and determiningthat the geographic area associated with the offer is at least partiallywithin the queried geographic area and in response sending the offer tothe publisher from which the request was received.
 17. The method ofclaim 12, wherein sending the offer to publishers comprises sending apublisher-and-offer specific uniform resource identifier (URI), and theoffer content sent to the user device configures the user device toreturn to the affiliate-network system any user interactions with theoffer.
 18. The method of claim 12 further comprising dynamicallyadjusting the terms of offers based on feedback from multiple channelsof offer redemption, including on-line and in-store redemptions.
 19. Themethod of claim 12 wherein sending the offer to publishers comprisessending a publisher-and-offer specific uniform resource identifier (URI)that configures a browser to retrieve content from the affiliate-networksystem.